public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Graham Seale <graham@southline.net>
To: linux-kernel@vger.kernel.org
Subject: 2.6 kernel, 2.4 kernel, keyboard input handling
Date: Fri, 22 Apr 2005 23:33:18 +0100	[thread overview]
Message-ID: <42697BAE.9020902@southline.net> (raw)

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@southline.net    (offline 01:00 to  08:00 UTC)
graham.seale@zen.co.uk   (this is 24 hour)

             reply	other threads:[~2005-04-22 22:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-22 22:33 Graham Seale [this message]
2005-04-22 23:51 ` 2.6 kernel, 2.4 kernel, keyboard input handling Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42697BAE.9020902@southline.net \
    --to=graham@southline.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox