--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> 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?
>
In this(the above) model this may work. How will Xorg handle VT swaps in
the above model?
> 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.
>
That seams like a good plan, thought current user space multi-'screen'
implementations leave much too desier. 'detachtty' seams like the best
one, but it dosen't directly support switching tasks.
Befour this idea will get off the ground a good system too handel this in
userspace is needed, I think. I don't think that this app/daemon would
have anything todo with mode setting or video drivers, exept the console
drivers allready provided by most OSs.
> The sysfs scheme has the advantage that there is no special user
> command required. You just use echo or cp to set the mode.
>
We allready have programs that change the video mode. It's true thay lack
support for some things, but I can't see the harm in adding on to existing
mode-setting programs.
If that's not good enuff there's no reason that the userland hotplug
script/program can't also provide these features if called by a non-root
user. If called by root, it just dose what it's told /wo the hp or mode
setting ioctl.
> 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.
>
/etc/mtab is a good concept, you might want to put this some where in /var
thought. Then there's no need to TSR.
> > 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.
>
So can we link fb to drm, for compatibility reasons?
> 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.
>
I don't see this as more then a fue more ioctls or rather just appending
some data on the end of existing structures to say what
location/framebuffer to attach too or create.
The other code has tobe done no matter what.
> --
> Jon Smirl
> [EMAIL PROTECTED]
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
-------------------------------------------------------
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
