[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Console switching ioctls

From: Marco Gerards
Subject: Re: Console switching ioctls
Date: Thu, 25 Aug 2005 19:19:01 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:

Hi Samuel,

> Marco Gerards, le Thu 25 Aug 2005 17:01:01 +0200, a écrit :
>> There are several ioctls related for console switching.  The most
>> important one is VT_ACTIVATE which is easy to implement.
> How is it easy to implement? You need to know which console client this
> needs be sent to (there may be several of them).

That is right.  But when you have access to a console it is easy.

> On a machine with a single vga card, this is easy: the user expects
> VT_ACTIVATE to be sent to the only client using the vga driver.

You always call VT_ACTIVATE on a opened node.

>> Our problem is that the ttys (/dev/tty1 for example) are not
>> responsible for the state, all these things are under control of the
>> console client.  One thing we can do is making nodes for each VT
>> (/dev/cons/[1-6] or whatever is required).  These nodes can be used to
>> access the console client (and the VT_* ioctls).  The problem with
>> this approach is that the access is not via the responsible tty.  So
>> the programs using this should be Hurd aware anyway.
> Maybe ttys can redirect ioctls to the console server, which redirects
> them to the proper console client?

How can it do that?  I think this makes things very ugly and over

>> A program can reserve a VT and request a notification when switching
>> to or away from that VT.  The notification is done with a signal.  But
>> I think there is no way in the Hurd to figure out where to send it to.
>> So how can I get the PID of the process calling VT_SETMODE?
> Maybe this could be sent by the console client to the console server,
> which sends it to the tty, which eventually delivers the appropriate
> signal to the program?

Right, but how do you know the PID of the program?  There is no way to
figure that out when VT_SETMODE is called, AFAIK.  We can change
VT_SETMODE so you can pass your PID, but that also breaks

>> So I am considering a library that is capable of the same things as
>> the ioctls.  Would that be a wise choice or is there any way to
>> overcome the problems I described?  My choice would be a library that
>> should be used for console switching, although it will make us
>> incompatible.
> Well, incompatible with what? X servers, openvt, svgalib, getty, not
> that much more. All these could be patched. This is painful however, so
> having some compatibility ioctl()s could be nicer. For more powerful
> console control (get the list of console clients reading the vt, ...), a
> library may be more suitable, I don't know.

Right, such programs.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]