On Fri, Jun 15, 2018 at 09:02:52PM +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2018-06-15 20:48:49) > > On Fri, Jun 15, 2018 at 07:44:08PM +0100, Chris Wilson wrote: > > > Quoting Ville Syrjala (2018-06-15 18:44:05) > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > Validate that all display timings fit within the number of bits > > > > we have in the transcoder timing registers. > > > > > > > > The limits are: > > > > hsw+: > > > > 4k: vdisplay, vblank_start > > > > 8k: everything else > > > > gen3+: > > > > 4k: h/vdisplay, h/vblank_start > > > > 8k: everything else > > > > gen2: > > > > 2k: h/vdisplay, h/vblank_start > > > > 4k: everything else > > > > > > > > Also document the fact that the mode_config.max_width/height limits > > > > refer to just the max framebuffer dimensions we support. Which may > > > > be larger than the max hdisplay/vdisplay. > > > > > > In the ddx, I used them to filter max hdisplay/vdisplay... And > > > completely ignored them wrt to framebuffer. > > > > Whatever works :) > > Yeah, and this doesn't break -intel afaict, since ultimately validation > is done by the kernel and we/the client just keeps on trying something > until it works (or more often until they just give up). Yeah. The main issue is the user being presented with a pile of modes that can never actually work. It shouldn't be fatal but at least it's annoying to the user. I think we might want a new ioctl to have the kernel validate user modes as well. I guess we could try to ressurect the old ioctls to add/remove modes to the other list, but I'm thinking we might just want something that takes the connector ID and a pile of modes and returns a good/bad status for each (could snatch one of the mode type or flag bits for that I suppose). -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
