2.6 kernel, 2.4 kernel, keyboard input handling

[Graham Seale]

Hello kernel developers

Please forgive this format, which cannot conform to your standard bug 
reporting system because of its hardware sensitive nature. It cannot 
allow a developer exact replication of the problem circumstance. I do 
not have close knowledge nor expertise with source codes and scripts 
involved. I can only report what I have now clearly perceived and 
verified, in the only way I know how. My experience of Linux is limited 
to trying out several distributions, and opting for a Stage1 compiled 
Gentoo, which now works.

For my examples, I refer specifically to..
kernel "linux-2.4.30/drivers/input/*" as mostly functional version.
Kernel "linux-2.6.11.7/drivers/input/*" as the version with problems.

Essentially, there is a fundamental difference in the way the 2.4 kernel 
manages keyboard and mouse inputs as compared to the 2.6 kernel which 
makes the system intolerant of temporary absence of expected inputs as 
occurs when KVM (thats Keyboard Mouse Video) hardware switchers are 
used. With the 2.6 kernel, there are many examples of mouse and keyboard 
problems that are cannot be always blamed on brand-specific hardware 
nonconformities.

The problems I describe occur with ALL distributions I have tried, when 
installed in hardware Pentium P3 (Coppermine) processor on ABIT VT6X4 
motherboard with 439.9Mb memory.  I am soon to try it with  AMD Athlon 
on ASUS AN78X .

This knowledge has been hard won! There can hardly be a less efficient 
way to begin to perceive that a problem is kernel-related than by doing 
Gentoo installs only to find the keyboard is suddenly useless on that PC 
when the switcher hardware is perfectly OK when switching between other 
Windows and Linux system computers.

I now have verified that ALL distributions I have tried, featuring the 
2.6 kernel are incapable of robust and flexible response to such switchers.
Please note that modern KVM switchers are built to artificially simulate 
the presence of a keyboard on the non-selected PC input because before 
XP, Windows computers were unable to tolerate keyboard disconnection.

The loss of keyboard function is independent of the environment, whether 
using GUI applications (various) or command line only.

The response of the 2.4 kernel is much more able to re-establish 
keyboard polling sync. Generally, as the Linux GUI is restored, there 
are random input states that might bring up the menu (unasked), and this 
will go away after one or two mouse clicks on the screen. If a "freeze" 
does happen, it may be cleared by switching away, then back to the Linux PC.

I understand that the system is pre-emptive multitasking, with a "user" 
space, a deeper "kernel" space, all policing access to real hardware 
instructions, and that the timeslice priorities are dynamically reworked 
by a special algorithm. I would not presume to delve into these without 
much more reading on my part. I would request that you help to bring my 
concern to the attention of those who created this code.

In my situation, as the 2.6 kernel becomes more widely adopted, so am I 
locked out from using and learning on the Linux PCs which have to share 
hardware with Windows users. It seems a pity that in this respect, the 
2.6 kernel cannot do what the 2.4 kernel could adequately manage.

Thank you for listening.
My regards
Graham Seale
graham@xxxxxxxxxxxxx    (offline 01:00 to  08:00 UTC)
graham.seale@xxxxxxxxx   (this is 24 hour)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/