Re: Design for setting video modes, ownership of sysfs attributes

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sun, 2004-09-19 at 08:12, Jon Smirl wrote:

> I'm still undecided if there needs to be a root priv daemon caching
> the EDID and polling for a monitor change. EDID can be regenerated on
> each request to change mode but it takes a few seconds. The root priv
> daemon will dynamically link to card specific libraries. Initially I'm
> going to add the functions to the mesa libraries but they may get
> broken out later.

I'd rather have the kernel driver do the actual probing and provide
the EDID or other infos for non-EDID capable monitors to userland (via
hotplug maybe ?), though userland can then of course decide to
"override" it and it's still userland that decodes it etc....

There are various cases of HW hackery involved in proper monitor
detection that I'd rather not see in userland anymore. Also, some cards
may provide an interrupt for detecting connector state change.

> > There is another thing I can't see.  Why can't the module for the drm
> > create fb[0-9]* devices, one for each monitor?  This would seam to solve
> > the problem with having another app and ioctl(API).
> 
> The DRM driver I'm working on already creates one DRM device for each
> head. Doing this also creates a sysfs entry for each head too. Each
> head has it's own mode/modes attributes.
> 
> Another item is merged fb. Initially heads will be unowned. Logging
> into a head makes you the owner. If you ask for the modes available on
> your head the list will also contain merged fb mode. If you set a
> merged fb mode, the login process on the secondary screen needs to be
> killed. If some one is logged into the secondary head merged fb modes
> won't be in the list. This scheme has the nice side effect of making
> all heads equal, there is no separate controlling device for the card.
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>