Re: gpm, USB mouse, Linux 2.4.4

[Daniel Martin <dtmartin24@home.com>]

Brian May <bam@debian.org> writes:

> Similarly, if I strace/ltrace the gpm process, it is definitely
> processing this input. It (reads 1 byte, opens /dev/tty0, does an
> ioctl operation: ioctl(4, 19259, 0xbffffc18), and then closes
> /dev/tty0) x 3. It seems a bit weird it wants to access /dev/tty0 so
> often, as that isn't my active console, but I will assume that is
> normal.

Actually, /dev/tty0 _is_ your active console; /dev/tty0 is another way
of accessing the currently active screen, as opposed to, for example,
/dev/tty3 which is the third console whether or not it's active.  And
that ioctl is to be expected:

cush:~$ grep KDGETMODE /usr/include/linux/kd.h
#define KDGETMODE       0x4B3B  /* get current mode */
cush:~$ perl -e 'print hex(shift),"\n";' 0x4B3B
19259

And then the console_ioctl man page says in part:

       KDGETMODE
              Get text/graphics mode.   argp  points  to  a  long
              which is set to one of the above values.

(The "above values" are 0 for text and 1 for graphics mode)

Now, as to whether or not the triple closing is normal, I can't tell
you as my box is currently 50 miles away so restarting gpm and then
moving the console-connected mouse is a bit difficult at the moment.

The obvious question now (for me at least), is whether or not that
ioctl is returning the correct values to gpm - that is, maybe gpm
thinks that it's in graphics mode even when it isn't.  I'd try a short
test program, such as:
perl -e 'open(F,"</dev/tty0");ioctl(F,19259,$a);print unpack("b",$a),"\n";'
(run as root, of course)
and then see that you get 0 when in text mode and 1 when in X.  On my
(2.2 series kernel) that perl line works as expected.