mån 2019-04-15 klockan 15:43 +0300 skrev Ville Syrjälä: > On Mon, Apr 15, 2019 at 10:57:52AM +0000, Lankhorst, Maarten wrote: > > fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar: > > > Introduced a client cap for advance cap mode > > > capability. Userspace should set this to get > > > to be able to use the new gamma_mode property. > > > > > > If this is not set, driver will work in legacy > > > mode. > > > > > > Suggested-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > Signed-off-by: Uma Shankar <uma.shankar@xxxxxxxxx> > > > > Nack, this doesn't seem like a sensible idea. We already guard it > > behind the gamma mode property. Userspace shouldn't set the gamma > > mode > > to a value it doesn't understand. > > Old userspace wouldn't know what a gamma_mode prop is. While a client > cap isn't an entirely satisfactory solution I can't think of a better > way at the moment. > > Well, maybe the old "hey kernel, please reset all my props to some > sane default" idea could be another way to deal with this sort of > stuff. Yes, but this approach wouldn't work, lot of other properties that can cause problems when not reset, like plane alpha and blend mode. I don't see why gamma is special in that case. If userspace did set it to some special value, then presumably it knows how to reset it too. It would be different if the split gamma mode was the default. Then I would understand this, but right now this would even break s/r. ~Maarten
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
