Re: Proposal: Hotkey-handling with kerneld
Gonzalo Tornaria (gtornari@varela.reu.edu.uy)
Sun, 28 Apr 96 8:12:44 GMT
Martin Buck <Martin-2.Buck@student.uni-ulm.de> wrote:
> Great. This does exactly what I've been thinking about. Is there
> anybody who thinks this shouldn't become a part of the standard
> kernel before 2.0? I know we have a code freeze, but the changes
> to the kernel are really very small and probably can't break
> anything.
It would be great. However, we should think a bit in the format of the
messages. Now, it's just a unsigned char that is sent (the number of the hotkey
that was pressed). Should we put more structure to de msgs? For one,
it would be good to have info about key releases; when a key is press the first
time and when is an auto repeat, etc. That is the info we have in the
keyboard.c handler, so why don't pass it. Should we use another channel for
key releases, or Yet Another Message Sub-Type?
struct msg_kbdreq{
unsigned char type;
unsigned char key;
unsigned char flags;
unsigned char reserved;
}
Where type is either CONSOLED_PRESS or CONSOLED_RELEASE. key is the number
of the hotkey that was pressed/released. In flags we could put "rep". What do
you think?
> Maybe it might be useful to use keysym-names which are a bit more
> descriptive like Hot0..Hot255. These names are stored only in
> loadkeys/dumpkeys, so they don't waste precious kernel-memory.
Yes, you can put whatever you like. I choose K0..K255 for simplicity. It's
not too important, anyway. I think the kernel side is priority (specially if we
want it in 2.0).
> Also, it might be useful to have a configuration file for
> consoled that allows you to control which program gets exec'd for
> which hotkey instead of running do_kbdreq which then has to exec
> yet another program [Gonzalo: I'll add this to consoled if you
> don't want to do it yourself].
I've done this... I still use system() (directly!), but I'm
planning to change it to fork()/exec() (it should be better,
shouldn't it?). Unless there is a good reason to keep using
system(). The new version is like the other in
<http://www.cmat.edu.uy/~tornaria/consoled/>
> It should also be possible to run the programs with the uid of
> the user who is logged in on the current console instead of uid 0.
> Is it possible to get this uid from user-space or should this
> information be set from kernel-space together with
> the consoled-request?
Mmm.. what if nobody is logged? You trigger the hotkey as uid 0? You
don't trigger hotkeys when nobody logged? You make it configurable for each
hotkey?
I will take a look... Does somebody know how to get that uid (that of the
user who is logged in on the current console)?.
Gonzalo