On Sat, 18 Sep 2004 12:58:07 -0700 (PDT), Mike Mestnik <[EMAIL PROTECTED]> wrote: > This is intersting... > I'd like to know how you plan to use VCs? That is more then one tty > sharing the same monitor. I'd also like to see VCs able to change modes > while not being active, thought I can't imagin how one would plan todo > this /wo blocking. I don't see any good reason why it can't be an ioctl, > you can have the same exe/bin/app handle BOTH the user and root parts of > the mode change. This way it can keep a cache of things, like modes that > will currently not be valid.
VCs should be dealt with at a higher layer. This higher layer would track what mode is on each virtual console and set it back after console swap. The VC code would provide it's own sysfs mode attribute in the VC's sysfs entry. A VC layer may suppress direct access to the head specific mode attribute. This brings up a question, how do I know which sysfs VC entry corresponds to the one I'm logged into? I'm trying to allow for a user space VC implementation at some point in the future so I don't want to build assumptions about a kernel space VC implementation into the code. The sysfs scheme has the advantage that there is no special user command required. You just use echo or cp to set the mode. 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. > 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. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel