30-bit X session and programs requiring 24-bit depth

[Ilya Anfimov]

On Mon, Feb 17, 2020 at 04:01:35PM +0700, Antoine Martin wrote:
> On 17/02/2020 15:51, Ilya Anfimov wrote:
> > On Sat, Feb 15, 2020 at 12:32:15AM +0700, Antoine Martin wrote:
> >> On 14/02/2020 18:53, Marek Szuba wrote:
> >>> Hello,
> >>>
> >>> I do quite a lot of photo editing on my box and with both my monitors
> >>> and my graphics card (amdgpu) supporting 10-bit colour channels, I tend
> >>> to run X at colour depth 30. Unfortunately some software, most notably
> >>> programs using OpenGL it seems, refuse to run in this mode - presumably
> >>> (I have seen this mentioned as the reason of problems with 30-bit mode
> >>> under Windows when the first cards supporting it came out) because the
> >>> software assumes 8-bit alpha channel but with the frame buffer still
> >>> being only 32-bit it is only 2-bit. Seeing as there seem to be no way of
> >>> switching colour depth on the fly, the best I have been able to come up
> >>> with is two separate X sessions - one at depth 30 and one at 24.
> >>>
> >>> Is there, or perhaps will there be some way in the near future, to work
> >>> around this problem - either by increasing framebuffer BPP (tried it a
> >>> while ago but it didn't seem to accept anything more than 32), using a
> >>> virtual X server (tried using Xephyr but it complained about there being
> >>> no matching screen), or some other way I haven't thought of?
> >> If you don't mind the indirection this introduces:
> >> xpra start --start=xterm --attach=yes
> >> This will start your application (ie: xterm) on a 24-bit virtual
> >> framebuffer and display it on your local 30-bit display.
> > 
> >  And with software-only OpenGL.
> If you want accelerated OpenGL within the xpra session, use VirtualGL:
> https://xpra.org/trac/wiki/Usage/OpenGL
> ie:
> xpra start --start="vglrun xterm" --attach=yes
 

  If  virtualgl  could  be used -- then yes, but then there is no
need in xpra.
  virtualgl itself has some other thin moments.

> >  xpra itself is not really good at either proxying or accelerating
> > glx/dri.
> Xpra doesn't even attempt to do these things, that's not its job.

 Well, I don't agree with that either, but the result is the same.