public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.6 kernel, 2.4 kernel, keyboard input handling
@ 2005-04-22 22:33 Graham Seale
  2005-04-22 23:51 ` Dmitry Torokhov
  0 siblings, 1 reply; 2+ messages in thread
From: Graham Seale @ 2005-04-22 22:33 UTC (permalink / raw)
  To: linux-kernel

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)

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: 2.6 kernel, 2.4 kernel, keyboard input handling
  2005-04-22 22:33 2.6 kernel, 2.4 kernel, keyboard input handling Graham Seale
@ 2005-04-22 23:51 ` Dmitry Torokhov
  0 siblings, 0 replies; 2+ messages in thread
From: Dmitry Torokhov @ 2005-04-22 23:51 UTC (permalink / raw)
  To: Graham Seale; +Cc: linux-kernel

Hi,

On Friday 22 April 2005 17:33, Graham Seale wrote:
> 
> 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 am a bit confused here... You are saying "loss of keyboard function"
but then mention mouse clicks. What is that you lose - keyboard or mouse
or both?

We know about problems with KVMs and mice but keyboards usually work just
fine with 2.6... 

-- 
Dmitry

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-04-22 23:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-22 22:33 2.6 kernel, 2.4 kernel, keyboard input handling Graham Seale
2005-04-22 23:51 ` Dmitry Torokhov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox