On 17/02/2020 16:40, Ilya Anfimov wrote: > 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 will tunnel 32-bit / 30-bit rendering to a real GPU but it won't change the X11 visuals that the application sees when connecting to the X11 server, and when applications fail to render at 30-bit it is usually because they can't find a matching X11 visual, not a GL visual. 30-bit displays will happily give you regular 24/32-bit OpenGL rendering contexts.
Antoine > 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. > _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s