On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner > <mario.kleiner.de at gmail.com> wrote: >> On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >>> >>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner >>> <mario.kleiner.de at gmail.com> wrote: >>>> >>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote: >>>>> >>>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set >>>>> still only gets called with a 256-entry LUT? If so, that works nicely >>>>> here, but is not intuitive :) >>>> >>>> >>>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it, >>>> and forget almost immediately how stuff fits together when i don't look >>>> at >>>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in >>>> xf86RandR12CrtcComputeGamma(), see >>>> >>>> >>>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5 >>>> >>>> for the latest. I'll propose that one to get cherry-picked into the >>>> server-1.19 branch as well. >>> >>> >>> Hrmph. That means we should try to adjust the gamma_set helper to do >>> the sampling when receiving a 1024-sized LUT, if people will use older >>> X servers (seems likely). Should hopefully be straightforward, to >>> handle just that one case. >> >> >> I think we never receive anything but a 256 slot LUT via gamma_set afaics? >> The server initializes xf86Crtc's gamma_size to 256 at startup, and none of >> the ddx'es ever overrides that with actual info from the kernel. >> >> What happens on older servers without that patch iff color depth 30 is >> selected is simply that the gamma table updates no-op, so the server runs >> with an identity gamma table setup at startup. Not perfect, but also not >> that bad, given that probably most people run their setups with a gamma of >> 1.0 anyway. At default depth 24 stuff works as usual. > > Ah OK. That's not so bad. I'll try to play around with it this week. > Thanks for the explanation!I just tested this out against xorg 1.19.5. With your patch, I get an extremely dark screen. I think it's just getting the first 256 of the 1024 values (I checked -- gamma_set is still only getting 256 values). So we have to do something a bit cleverer to fix this scenario... ideas? -ilia
On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:> On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner >> <mario.kleiner.de at gmail.com> wrote: >>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >>>> >>>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner >>>> <mario.kleiner.de at gmail.com> wrote: >>>>> >>>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote: >>>>>> >>>>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set >>>>>> still only gets called with a 256-entry LUT? If so, that works nicely >>>>>> here, but is not intuitive :) >>>>> >>>>> >>>>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it, >>>>> and forget almost immediately how stuff fits together when i don't look >>>>> at >>>>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in >>>>> xf86RandR12CrtcComputeGamma(), see >>>>> >>>>> >>>>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5 >>>>> >>>>> for the latest. I'll propose that one to get cherry-picked into the >>>>> server-1.19 branch as well. >>>> >>>> >>>> Hrmph. That means we should try to adjust the gamma_set helper to do >>>> the sampling when receiving a 1024-sized LUT, if people will use older >>>> X servers (seems likely). Should hopefully be straightforward, to >>>> handle just that one case. >>> >>> >>> I think we never receive anything but a 256 slot LUT via gamma_set afaics? >>> The server initializes xf86Crtc's gamma_size to 256 at startup, and none of >>> the ddx'es ever overrides that with actual info from the kernel. >>> >>> What happens on older servers without that patch iff color depth 30 is >>> selected is simply that the gamma table updates no-op, so the server runs >>> with an identity gamma table setup at startup. Not perfect, but also not >>> that bad, given that probably most people run their setups with a gamma of >>> 1.0 anyway. At default depth 24 stuff works as usual. >> >> Ah OK. That's not so bad. I'll try to play around with it this week. >> Thanks for the explanation! > > I just tested this out against xorg 1.19.5. With your patch, I get an > extremely dark screen. I think it's just getting the first 256 of the > 1024 values (I checked -- gamma_set is still only getting 256 values). > So we have to do something a bit cleverer to fix this scenario... > ideas?Mario, Have you given this any thought? Is there a way to detect one or the other scenario? I'd rather not put something in where we check the X version at compile time. Did the ABI get bumped in 1.20 perhaps? -ilia
On Sat, Apr 28, 2018 at 7:22 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:> On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner >>> <mario.kleiner.de at gmail.com> wrote: >>>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >>>>> >>>>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner >>>>> <mario.kleiner.de at gmail.com> wrote: >>>>>> >>>>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote: >>>>>>> >>>>>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set >>>>>>> still only gets called with a 256-entry LUT? If so, that works nicely >>>>>>> here, but is not intuitive :) >>>>>> >>>>>> >>>>>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it, >>>>>> and forget almost immediately how stuff fits together when i don't look >>>>>> at >>>>>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in >>>>>> xf86RandR12CrtcComputeGamma(), see >>>>>> >>>>>> >>>>>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5 >>>>>> >>>>>> for the latest. I'll propose that one to get cherry-picked into the >>>>>> server-1.19 branch as well. >>>>> >>>>> >>>>> Hrmph. That means we should try to adjust the gamma_set helper to do >>>>> the sampling when receiving a 1024-sized LUT, if people will use older >>>>> X servers (seems likely). Should hopefully be straightforward, to >>>>> handle just that one case. >>>> >>>> >>>> I think we never receive anything but a 256 slot LUT via gamma_set afaics? >>>> The server initializes xf86Crtc's gamma_size to 256 at startup, and none of >>>> the ddx'es ever overrides that with actual info from the kernel. >>>> >>>> What happens on older servers without that patch iff color depth 30 is >>>> selected is simply that the gamma table updates no-op, so the server runs >>>> with an identity gamma table setup at startup. Not perfect, but also not >>>> that bad, given that probably most people run their setups with a gamma of >>>> 1.0 anyway. At default depth 24 stuff works as usual. >>> >>> Ah OK. That's not so bad. I'll try to play around with it this week. >>> Thanks for the explanation! >> >> I just tested this out against xorg 1.19.5. With your patch, I get an >> extremely dark screen. I think it's just getting the first 256 of the >> 1024 values (I checked -- gamma_set is still only getting 256 values). >> So we have to do something a bit cleverer to fix this scenario... >> ideas? > > Mario, > > Have you given this any thought? Is there a way to detect one or the > other scenario? I'd rather not put something in where we check the X > version at compile time. Did the ABI get bumped in 1.20 perhaps? > > -iliaNope, haven't had time to retest on 1.19, too much "fun" trying to tame all those new server 1.20 bugs which got in the way of depth 30 stuff. I think the video ABI got bumped in 1.20. -mario