[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Repeater for the console client
From: |
Marco Gerards |
Subject: |
Repeater for the console client |
Date: |
Sun, 18 Jul 2004 20:31:07 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Hi,
At the moment I am working on a repeater option for the keyboard
driver of the console client. I will do the same for the mouse driver
I am writing.
Because not everyone is familiar with the console client I will start
with some background information. The console client is a very small
program that links to libcons and communicates with the console server
using this library. To make this program useful it can load drivers,
which are simply so-libraries.
Most people use the `vga' and `pc_kbd' drivers. At the moment I am
writing `pc_mouse'. To make it possible to start xfree while the
console client is started a repeater will be used. That is simply a
translator that is started from (for example) the `pc_kbd' driver.
This is required because only one program can open the Mach device.
Some months ago I wrote a patch to add such functionality to
`pc_kbd'. In order to do this I simply used libtrivfs. This worked
perfectly. Now I can start xfree while the console client is active.
Using the repeater like: `-d pc_kbd --repeat=/dev/kbd' a keyboard
translator is set on the /dev/kbd node.
After that I started working on the `pc_mouse' driver. This will add
xterm like mouse support to the console. In addition to that I want
to use this to replace the mouse translator that is used in debian.
To do this I have to add a repeater option to this driver like I did
for pc_kbd.
In case you have not guessed already, I encountered a program with
libtrivfs. It is not possible to use libtrivfs twice from within the
same program (once from pc_kbd and once from pc_mouse). Is there some
way to make this possible? I must admit I don't know much about the
dynamic linker, but I could not find anything that could help me from
studying documentation I found.
Two other solutions i can think of are:
1) Changing libtrivfs. Perhaps by making a struct in which the
calback function addresses and global variables are stored.
2) Using netfs to create /dev/console/ (the path is configurable, of
course) in which translators can be stored. This requires a change
to the console client. In that case the console client sets up the
/dev/console/ translator and drivers can use some special function
to set up a translator in that directory.
Any feedback is appreciated. I really hope other people might have
other ideas to deal with this problem. Otherwise please tell me if
either solution #1 or solution #2 is acceptable so I can continue
hacking.
Thanks,
Marco
- Repeater for the console client,
Marco Gerards <=