On Tue, May 29, 2018 at 10:16:20AM +0300, Tomi Valkeinen wrote: > On 29/05/18 09:42, Daniel Vetter wrote: > > > Thus far the rules has been that we try to put the integrated panel first, > > and that's it. See drm_helper_move_panel_connectors_to_head(). If there's > > Ok. But we may also have multiple integrated panels. > > > any standard, then imo that's it. Not a more generic "the first display is > > the preferred one" because frankly we don't know that - or how do you > > guess that I want to use my laptop just as a work-station, and never use > > the integrated panel when the hdmi thing is connected? You need > > configurability in userspace and fbdev for that. > > I can't guess, which is why we added this parameter. I agree that (ignoring > fbdev for now) the userspace should handle this. But as described in > drm_helper_move_panel_connectors_to_head(), this isn't the case at the > moment. > > > And yes, for fbdev some fbdev option would probably be best. We already > > have options/parsing to disable/force certain connectors, we could also > > have another flag to designate it the preferred primary. > > It's true that the only important thing here is the "primary", i.e. we don't > care how the second or third displays are ordered. > > We wanted to use the connector names here in the parameter, but connector > names are not available before the connectors are created, so we ended up > with the list of numbers... > > > Also, the only thing where primary/secondary matters for fbdev emulation > > is for the vblank handling. Afaiui that was added for the gpu blob drivers > > being stupid and refusing to use kms. Definitely don't want to add huge > > driver-specific hacks for that :-) > > For us it was about the fbdev size, which was setup at probe time to the > size of the first display (Or smallest of the connected ones? I can't > remember). We wanted the fbdev size to be the size of the "primary" display. It's smallest of all connected ones. Atm you do not get fbdev size == size of primary. It's only >= size of primary. And no way to modeset :-/ > > Imo the fbdev one makes some sense, but if the only reason for it is the > > userspace gpu blob maybe not so much. For everything else, you need some > > form of configuration in userspace anyway. KMS doesn't have a concept of > > "primary" display, and I have no idea how we'd even make that happen > > everywhere. > > We were not aiming at a "primary" display in the sense that it'd be > something that the userspace should care about. More like a > fallback-primary-display, in case the userspace only uses the first > connector. > > But I do agree that this feels hacky. So we can carry this in the TI kernel > for now as a temporary measure. One even more impressive hack would be to have this generic in the drm core. I.e. at drm_dev_register time we'd move the primary connector to the front. Only issue is that this might upset the driver, so we might need to do that only for the getresources ioctl (and not for anything else). The problem with that is that drm connectors have no unique/stable names, so I'm not sure how we could make this work correctly .... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
