Samuel Thibault <[EMAIL PROTECTED]> 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 complicated. >> 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 compatibility. >> 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. -- Marco _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
