On Fri, Jul 11, 2003 at 12:23:15PM -0400, Mark L. Kahnt wrote:
> On Tue, 2003-07-08 at 20:24, Pigeon wrote:
> > From "man kbd" for X 4.3.0: (Doesn't exist in earlier versions)
> >
> > The following driver Options are supported:
> >
> > Option "Device" "string"
> > Specify the keyboard device. Default: the OS's
> > default console keyboard input source.
> >
> > This is /dev/console, right? No... explicitly specifying
> > Option "Device" "/dev/console" gives me garbage. /dev/kbd? Only exists
> > on SPARC. /dev/tty-I-started-X-from? No. /dev/xconsole? No, that's not
> > "the X version of /dev/console" but a special fifo for the xconsole
> > program.
> >
> > What I want to do is find out which /dev entry the above "default
> > console keyboard input source" refers to, then tell netcat to copy
> > /dev/whatever on a machine A without X to a fifo on a machine B which
> > is running X. XF86Config on machine B then specifies
> > Option "Device" "my-special-fifo" as its keyboard device. I can then
> > use X on machine B, with machine B's mouse and display, but with
> > keyboard input coming from machine A.
> >
> > But which /dev entry is it? Experimenting either gives me garbage or a
> > crash, /usr/share/doc/xspecs is of no help; Google has only given me
> > the negative result that /dev/kbd is only on SPARC. If only that
> > man page entry said "Default: /dev/somethingorother"...
> >
> > Can anybody help me fill in the blank please?
>
> Not up to 4.3 here, so I can only offer the technical side of why
> certain things didn't work. /dev/console is only the outbound stream of
> system (kernel and daemons) messages for logging review.
OK, I'm probably being thrown off track by the concept of Logging In
to The Console under Unix; but certainly under Linux if you cat
/dev/console it catches keyboard input from the VT you run cat from.
> My own
> suspicion is that it *could* be looking for the virtual console on which
> X11 is running, particularly if the virtual consoles are broken into
> multiple input and output file descriptors.
Unfortunately neither /dev/tty7 nor /dev/tty-I-started-X-from appear
to be valid choices.
Since my original post I've been poking through the source (a daunting
task; it's quite clearly written as source goes, but there's so f**g
much of it :-) ) I'm getting somewhere... if Option "Device" isn't
set, it uses the already-opened xf86Info.consoleFd, so an obvious next
possible step is to find where it opens that.
If Option "Device" is set, it takes the string as a filename and tries
to open it (in mode O_RDONLY | O_NONBLOCK | O_EXCL). The problem now
is to find out exactly what it expects to be reading from that... I
found some example code for a keyboard driver kernel module on the net
(apparently part of a programming course) and hacked it to buffer the
raw scancodes and present them on /dev/kbd. It's doing that OK, but if
I give it to X to read, I get *nothing*... Garbage, I could understand.
> Alternately, the XFree86 configuration is prone to defining devices
> individually higher in the file (InputDevice, Device, VideoAdaptor,
> Monitor,) and then assembling those pieces into a collection of devices
> that constitute the system they work at (the ServerLayout.) Could you
> post the segment where you find this line?
Sure... note the file was originally generated for a non-Debian source
build of X 4.2.0; all I've changed is the keyboard driver:
# File generated by xf86config.
<snip>
# **********************************************************************
# Input devices
# **********************************************************************
# **********************************************************************
# Core keyboard's InputDevice section
# **********************************************************************
Section "InputDevice"
Identifier "Keyboard1"
# This was the old keyboard driver, before 4.3.0
# Driver "Keyboard"
# 4.3.0 provides the new kbd driver...
Driver "kbd"
# which allows you to do this (but I can't get it working)
# Option "Device" "/dev/kbd"
# For most OSs the protocol can be omitted (it defaults to "Standard").
# When using XQUEUE (only for SVR3 and SVR4, but not Solaris),
# uncomment the following line.
# Option "Protocol" "Xqueue"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
# Option "Xleds" "1 2 3"
<and so on. Snip>
# compare with mouse section...
# **********************************************************************
# Core Pointer's InputDevice section
# **********************************************************************
Section "InputDevice"
# Identifier and driver
Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "ImPS/2"
Option "Device" "/dev/psaux"
# Option "FlowControl" "None"
<snip rest>
> Otherwise, I am not sure that I am picturing the configuration entirely
> correctly - the keyboard you are seeking to use is on a remote box to
> where X11 is running, but the mouse is on the system with X11?
Correct. "Remote" is only true in the sense of "on the other end of a
network connection"; physically the two boxes are right next to each
other, so it's not as weird as it sounds!
The intention is to get around the fact that it's apparently not possible
to set up a true dual-head system with X on one head and text consoles
on the other. The idea is for the more powerful box, the one with the
mouse, to run X and display the X desktop on its monitor. The less
powerful box, the one with the keyboard, runs in text mode, and
logging into any of its VCs automatically ssh-es to the bigger box.
tty7 on the lesser box is a custom setup to pass its keyboard input
via netcat to a fifo on the bigger box which I point the "kbd" driver
at. Or would do, if I could get "kbd" to recognise my input.
Sorry if I was unclear on this earlier - I should have had the cup of
tea before I posted, not after :-)
> I am not
> sure that anyone quite pictured that mix of input sources for one user.
Y'know, I'm beginning to get that impression too... :-)
> I'd suggest that maybe the familiarity with that level of configuration
> might be on the level of contacting the debian-x list, or XFree86.org
> directly.
Thanks, that's a useful idea [fx: shudders at thought of extra email
traffic :-) ]
--
Pigeon
Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Attachment:
pgphIAtxbRAGS.pgp
Description: PGP signature