Bug 141443

Looks like you're simply pressing much to long the F7 key.

If I held it down any less long I wouldn't even have touched it at all. I've tried all different lengths of hold down times, and normally release the F7 before releasing Alt (and Ctrl if I used that as well).

This is with systems running both PIII 800 MHz (OpenSuse) and Celeron 2.4 GHz (SuSE DVD), physically different keyboards, different video driver in xorg.conf (i810 & mga) and with vga=788 on Matrox system kernel line & with vga=0x0120 on i810 system kernel line.

FWIW if that matters, I have in kdmrc NumLock=On, and all desktop logins set to turn on NumLock, and have never tried without on, as I want NumLock never to be off ever for any reason whatsoever on any keyboard with separate numpad.

Also is triggered the main menu in Konsole if it has focus on reentry.

OOps. This is still 10.0.

Does this still happen with SUSE 10.1 (Beta8 is released now).

Did factory ftp install last night on a 3rd machine. Still broken. Coming back from tty1 to Firefox starts the Firefox caret browsing dialog.

Thanks for the status update.

No improvement as of rc2.

No improvement as of 10.1 final.

Could you check this issue with openSUSE >= Alpha3 again?

I just got done ftp installing factory. Coming back from tty1 to Chatzilla switches to tab 7. Still broken.

Hmm ... I still can't reproduce this issue. I'm afraid you need to switch back with "chvt 7" instead. :-( Thanks for testing!

Created attachment 97823 [details]
xorg.conf from 10.2 factory

This never happens in:
SUSE 9.3 and prior
Fedora Core 4
Mandriva 2006
Mandriva 2007 Cooker
Kubuntu 6.06

but it happens on multiple systems using:
SUSE 10.0
SUSE 10.1
SUSE 10.2 Factory

so it doesn't work for me. I cannot NOT reproduce it in 10.0+. How many systems can't you reproduce it on?

I'm switching often among various ttys including vt7, vt8 & vt9. Chvt 7 is 7 keystrokes, and not acceptable. 

> so it doesn't work for me. I cannot NOT reproduce it in 10.0+. How many 
> systems can't you reproduce it on?
I never run into this problem and Ctrl-Alt-Fx/Alt-Fx is something which I often use on many systems.
> I'm switching often among various ttys including vt7, vt8 & vt9. Chvt 7 is 7
> keystrokes, and not acceptable. 
Use an alias for this.

I can leave this bugreport open forever (since you will always reopen it again anyway), but this won't help anyone. :-(

Created attachment 97831 [details]
kdmrc from 10.2 Factory

Are you using en_US with 24 hour clock and metric measure system and usetheme=false? Is NUM on in all sessions? Are you using P4 or PIII or PII or K6 or Celeron? Are you using old 5 pin or PS/2 US keyboard with no windoz keys? I don't know what to look for, as I'm not a programmer.

I often see this too, especially on my main desktop machine running SuSE 10.0 and a development one with 10.1. However I have several other machines with 9.3, 10.0 and 10.1 where I rarely see it. 

Clearly some hardware is more prone to the problem than others.

Does anyone know if it occurs with other recent distributions? Maybe KDE version makes a difference?

HTH

Maybe it's time to change the keyboard (hardware)?

As noted here previously, problem occurs on 3 entirely different systems, including 3 entirely different keyboards. All 3 systems are multiboot with non-Linux plus other Linux distros, none of which exhibit any such problem. I have a number of other systems with various other distros that don't do this.

I just spent an obscene number of hours text mode installing from alpha4 CDs on a 4th machine (i815 video). To get X to work required I copy an xorg.conf from my Debian Etch partition (see bug 204324 and bug 204521 ). X runs 1400x1050 120 DPI.

This machine also displays the problem. The things I can remember personalizing before testing:

1-kernel config line ends in 'splash=0 vga=0x120 3' (I init 5 from tty1 to start KDM)
2-kdm changes:
a-commented AllowRootLogin
b-changed GreetFont from 20 to 24
c-changed StdFont from 10 to 14
d-changed FailFont from 10 to 14
e-uncommented ShowUsers
f-uncommented and removed johndoe from SelectedUsers
g-Changed from #UseTheme=true to UseTheme=false
3-copied .mc, .mozilla, bookmarks.html, .bashrc and .profile from Debian partition
4-set timestamping=on in /etc/wgetrc
5-turned nfsserver on with chkconfig
6-added HPFS partitions to /etc/fstab
7-added local network settings to /etc/hosts
8-added local network hosts to /etc/hosts.allow
9-changed /etc/hosts.deny
10-created /hpfs, /smbmnt & /nfs
11-set Konsole font to 10 DejaVu Sans Mono
12-set Konsole size to 100 by 32
13-turned on right panel hiding button
14-set quickstart menu to 10 most recently used

How many different systems would I need to duplicate this on in order to have this taken seriously? Right now I'm at 100% failure from at least 5 installations on 4 machines, but only with SUSE. KDE on at least 5 other distros on the same 4 machines doesn't have this problem.

I get this on both i586 boxes running 10.1 final, KDE3.5.4. However if you are quick, and I mean *really* quick, when hitting the F7 button, it doesn't happen. Try it out - it's a challenge!

I tested this on the 2 machines on my desk the result was
that the X86_64 desktop did not show the problem, but my i586 laptop
does every time. Both have french keyboard layouts.

Both machines are running up to date 3.5.4.

My machines tested above that exhibit the bug are as follows:
PIII 700M; AMI BIOS KB cps NA, delay NA; KDE KB cps 20, delay 250
Celeron 800M; AMI BIOS KB cps NA, delay NA; KDE KB cps 20, delay 250
PIII 933M; Dell BIOS KB cps NA, delay NA; KDE KB cps 20, delay 250
Celeron 2.4G; Phoenix-Award BIOS KB cps NA, delay NA; KDE KB cps 20, delay 250

Created attachment 98280 [details]
.xsession-errors immediately after fresh login and test using Konsole

Konsole was a saved session with two tabs, #1 normal, #2 mc. No idea what these errors are about.

Thanks for testing and the additional information. I'll investigate this issue once I can reproduce it on a machine.

Stefan, later is a bogus resolution for a condition like this. The only thing resolved so far is I'm not the only one with this problem. I am working to provide as much useful information as possible, and asked you a question in comment 21 that you have yet to answer. You may not have time to deal with this before 10.2 is released, but that doesn't make it any less a bug. Resolved later will only serve to cause others who might be able to help to think that this bug actually has been resolved and as a consequence forgo giving it attention.

I have since discovered that on rare occasions I can get the behavior that most experience, but have yet to figure out what it takes to get it. It worked as it should twice in a 24 hour period, out of probably 50+ cycles on two machines.

I've now figured out how to avoid the problem. How X is exited is the key. When I hold down ctrl-alt and then add F[1-6] to leave, the behavior on return depends on when I released F[1-6]. If I wait until X clears the screen before releasing, then behavior is as expected. If I release F[1-6] quickly, which is my normal habit with all keystrokes, and hard to remember not to do just for this purpose, then F7 executes on return to X.

Well, this doesn't help reproducing it for me. Ok, letting it open for the time being. Can't we set this at least to minor?

I don't think it's minor, but it seems P5 remains appropriate until you have more time available, based on how few people apparently can reproduce it.

Comment 28 was based upon testing only in 10.0. That workaround does not work in 10.2a4 on my i815 system.

Created attachment 98798 [details]
comparison of xorg.conf keyboard sections from most systems tested

Note that 2 of the 3 keyboards I use most are actually 101 key types. #3 is a 104. I have no idea what a 105 is.

still happening in 10.2 beta 1

I have the same behaviour in 10.2 RC1

I installed RC3 on yet another machine and have the problem on it too.

I just installed a minimal X alpha4 on Sempron/NForce system, then updated immediately with YaST System Update to current factory. KDE isn't even installed, only fvwm2, and it still happens, so changing summary from KDE to X.

I can see this behaviour, too. I have seen it for so long I don't remember.

I'm using gnome and 10.1 currently.

  - leave firefox with focus - I'm using gnome in 10.1 stock plus security
    patches.
  - switch to a text console via ctrl-alt-f1, for instance.   
  - switch back to X via alt-f7
  -  firefox pops up asking whether I want to enable caret browsing (F7
     turn caret browsing on (screen shot available)).

  - I can add more to this. If I switch to another workspace in gnome and
    back later to an xterm and some other apps, using the keyboard, extra
    meaningless text is inputted to the application (escape codes, I
    think). I can see the result in Pine, activating "unknown command"
    responses and in midnight commander (I use both apps a lot). It is
    random.

Following a mailing list response and comment 22 suggesting keystroke speed affected reproducibility, I tested 10.0 with a Keytronic keyboard, a 10.2 system with a Dell keyboard, and another 10.2 system with a Northgate keyboard. I found that consciously striking quickly enough on the Keytronic and Dell produced expected behavior. However, my old bones do not naturally move that quickly, and it is infinitely easy to produce the unwanted behavior moving at natural "speed". On the Northgate, I find it impossible to strike F7 quickly enough to not produce the unwanted behavior. Maybe the assignee could try a Northgate or Avant keyboard to try to reproduce with. Avant keyboards are high quality descendants of the high quality Northgates. http://www.cvtinc.com/products/keyboards/menu.htm

I'll investigate this issue once I can reproduce it on a machine.

This bug should remain open (and any others currently so "resolved") until it is really resolved.

Later is a bogus resolution. How can anything be "resolved" when nothing has been accomplished? When someone searches for an existing bug using the default search settings, resolved bugs are not searched for, which means the person searching will most likely clutter the system with a new bug that duplicates the unresolved "resolved" bug. v3 of the Bugzilla software has deprecated both REMIND and LATER and removed them from default possible resolutions: https://bugzilla.mozilla.org/show_bug.cgi?id=13534 

Is there some other information someone might provide to help you reproduce?

*** Bug 154176 has been marked as a duplicate of this bug. ***

We really should do something about this, as it is hitting numerous people. OTOH, I cannot reproduce this myself. Right now I don't have any clue what the difference actually is that makes this happen for some, and not for most others.

I have exactly the same keyboard section as you have. Can you please try logging in as a newly created user (or root) and check whether the same behavior exists? I.e. is it a system-wide effect or a user configuration based one?

Matthias, who are you speaking to? Did you read comment 0 and comment 13 ? This applies to me on all hardware tested (I have no USB keyboards) no matter what login is used. The only out of the ordinary configuration common to all of mine that I can think of is:
1-inittab default runlevel is 5, but I nearly always have booted with a 3 on the kernel line, and start kdm via init 5 only after housekeeping
2-I virtually always have 3 or more logins active on tty[1-6], with mc running on at least tty2
3-I use PS/2 port attached mice almost exclusively
4-kdmrc has:
a-numlock=on
b-usetheme=false
c-allownullpasswwd=true
d-allowrootlogin=true
e-showusers=selected
f-focuspasswd=true

I know you're (a bit?) frustrated, but for completeness, it would be great to be tested in a non-configured environment. root is almost always good enough here.

The remainder of your configuration doesn't show anything spurious, but I'm running out of ideas as well (I followed this bug a long time). Obviously something must be different to our configuration, because nobody here at SuSE could reproduce this so far.

This is like searching for a needle in a haystack in 20km distance with the naked eye...

I tried what you asked to check with xevin bug 174156.
The situation is better in 10.2, as I don't get automaticaly the "F7" key when switching back to VT7 as before.
BUT if I push  F1 or F7 without releasing the CTRL and ALT keys beforehand, I'll get F1 or F7 not CTRL-ALT-F1 or CTRL-ALT-F7. In Firefox this gives the help window or "carret dialog".
Attaching the xev.log and xorg.conf

Created attachment 111337 [details]
xev.log

Created attachment 111338 [details]
xorg.conf

I found two more machines that have this problem, but finally found one without it, a Dell C610/C640 laptop (is not mine).

(In reply to comment #44)
> The situation is better in 10.2, as I don't get automaticaly the "F7" key when
> switching back to VT7 as before.
> BUT if I push  F1 or F7 without releasing the CTRL and ALT keys beforehand,
> I'll get F1 or F7 not CTRL-ALT-F1 or CTRL-ALT-F7. In Firefox this gives the

AFAIK this is considered correct behavior. Ctrl-Alt was released when the VT switched, and from X perspective you haven't pressed them again yet.

Though it is strange that this is machine dependent. Probably some race condition. I assume this could be considered resolved, for a final fix an upstream bug report might have more visibility.

I did a fresh install of 10.2, fully updated it, and I have "the problem". When I jump from text mode to graphic mode using ctrl-alt-f7, I get this in the xterm I had there opened previously:

minas-tirith:~ # [18~

(I did not type the escape plus text)

Further more. In 10.1, when swithing from a window to another, specially with xterms, and speciall from one workspace to another (using gnome) I get keys popped into the jumped-to window, with unpredicatable results. This has been happening for years, it's not new. I mention this because it might be related to the current bug.

The same problem affects me - however, starting with 10.2. Maybe it has something to do with repeat rate or Xorg 7.1.99 - no idea.

/etc/sysconfig/keyboard:
KBD_RATE="30.0"
KBD_DELAY="250"

/etc/X11/xorg.conf:
Section "InputDevice"
  Option "AutoRepeat" "250 35"
EndSection

I'll see whether I can copy the bug. (Yes, something like that is possible.)

Reopen.

Any improvements with openSUSE 10.3 Beta1?

(In reply to comment #52 from Stefan Dirsch)
> Any improvements with openSUSE 10.3 Beta1?

None that I can find.

Ok, moving bug to 10.3...

Anyway, still nobody at SUSE could reproduce it so far. Closing as WORKSFORME.

You people just don't have enough types of hardware to test on, because I cannot not reproduce this using both AMD and Intel CPU systems.

Is everyone at SUSE using USB keyboards or something? I only use PS/2 port keyboards, all of which can reproduce. How can it be so easy for me to reproduce on many different systems and yet 0 SUSE developers can? What is different about SUSE keyboard handling that on no other distro can I reproduce, yet on every system with SUSE that I can?

WORKSFORME seems to be an impossible resolution for this reporter.

trying LATER.

Bug 164575 Bug 181575 Bug 214992 Bug 225674 & Bug 262002 prove comment 58 invalid. Comment 17 comment 22 comment 23 comment 33 comment 36 and others following prove others besides reporter encounter this.

I find this bug every day I use my computer.

I also attended a course two weeks ago, where I installed opensuse 10.2. I was happily surprised not to see this bug, and then it reappeared more or less when I switched from kde to gnome (with xterm, not gnome terminal).

That computer used both ps2 keyboard and mouse.

(In reply to comment #57 from Felix Miata)
> Is everyone at SUSE using USB keyboards or something? I only use PS/2 port
> keyboards, all of which can reproduce. How can it be so easy for me to

Of course I tried PS/2 as well. And I have PS/2 at home. Others in the company as well. Also, if that bug is related to the connector type, you might as well see me eating the printed out version of this bug.

Still, *nobody* here can reproduce.

> reproduce on many different systems and yet 0 SUSE developers can? What is
> different about SUSE keyboard handling that on no other distro can I reproduce,
> yet on every system with SUSE that I can?

That was exactly what we tried to find out. I'm out of ideas, really.
Do you have any special boot parameters? Or some unnormal BIOS settings? Special networking hardware that could create conflicting interrupts?

(In reply to comment #61 from Carlos Robinson)
> I also attended a course two weeks ago, where I installed opensuse 10.2. I was
> happily surprised not to see this bug, and then it reappeared more or less when
> I switched from kde to gnome (with xterm, not gnome terminal).

Does this mean this only happens with gnome?

Info about the system on which I most recently installed (last week, beta1):
# lspci
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
01:07.0 Multimedia controller: Philips Semiconductors SAA7130 Video Broadcast Decoder (rev 01)
01:09.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 04)
02:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 04)
# cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 8
model name	: AMD Sempron(tm
stepping	: 1
cpu MHz		: 1992.099
cache size	: 256 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up ts
bogomips	: 3987.16
clflush size	: 32
# cat /proc/interrupts
           CPU0       
  0:        259    XT-PIC-XT        timer
  1:       1584    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  6:          5    XT-PIC-XT        floppy
  7:         30    XT-PIC-XT        parport0
  8:          2    XT-PIC-XT        rtc
  9:          0    XT-PIC-XT        acpi
 10:          0    XT-PIC-XT        saa7130[0]
 11:       6073    XT-PIC-XT        eth0
 12:      28874    XT-PIC-XT        i8042
 14:      19326    XT-PIC-XT        ide0
 15:      45316    XT-PIC-XT        ide1
NMI:        262 
LOC:      96140 
ERR:          5
MIS:          0
# cat /proc/cmdline
root=/dev/disk/by-id/ata-Hitachi_HDS721616PLAT80_PV6904Z21A72SN-part22 noapic splash=0 vga=788 3
# uname -a
Linux m7ncd 2.6.22.1-16-default #1 SMP 2007/08/06 15:19:41 UTC i686 athlon i386 GNU/Linux

2005/12/21 Phoenix -AwardBIOS behavior is same whether BIOS Advanced has Typematic Rate Setting Disabled or set to 20cps/delay 250ms.

I've tried today with 3 Keyboards:
Northgate Omnikey 102 (normal)
Dell TH-04N454-37171-350-J745; Rev A00 (tested only)
IBM Model KB-9910 P/N 37L2551 (tested only)

In kdmrc I always have:
NumLock=On
Theme=
UseTheme=false

I did not try messing with kdmrc settings today, but have in the past tried the defaults without success.

I virtually always have a simple sh login on VC1, mc running on VC2, and top on VC6. In X I normally keep Konsole open with at least one plain session and one mc session.

As a test today, while not logged into KDE, I tried deleting all directories except .mc, .mozilla and bin from $HOME, plus all standard files except .bash_history, .bashrc and a few that have no impact on configuring anything, and then re logging in. It didn't help. Normally I have a number of personalizations:
standard KDE Menu Style on
screensaver set to 20min/60sec with both boxes unchecked
numlock=turn on
keyboard=repeat 20cps delay 250ms
anti-alias=medium
splash screen=blue bend
panels=show right button; animate off; menus name(description); max entries 10
taskbar=group never

Today on each return to X from VC either Konsole menu was activated or Firefox caret browsing dialog was triggered, regardless of settings changes. I'm out of ideas on things to try too. I do have yet another system recently acquired that I haven't tried any SUSE on yet. It is Intel motherboard with 845G chipset currently installed with Kubuntu 7.04 and W2K.

I just did a fresh install on the 845G, doing only as much customizing as was required to get X to work at all. I'm unable to activate Firefox or SeaMonkey caret browsing no matter what, nor automatically shift to CZ's #7 tab. Konsole's main menu I can activate only by holding keys down longer than some certain short time that I have yet to determine. So in essence, I've finally found a machine on which I cannot reliably duplicate this.

I reinstalled fresh from Beta1 KDE CD on the comment 20 machine, which is a Dell GX150 tower, a system readily available at low cost if eBay is any guide. Problem exists on it, while not on any of the other non-SUSE-post9.3 distros installed on it: Fedora 6, Fedora 7, Kubuntu Edgy (6.10), Debian Etch and Xandros 3. It also has SUSE 10.2 and 10.0 exhibiting the problem, and SUSE 9.3 not exhibiting the problem.

FWIW, I'm only testing at resolutions of 1400x1050 and above, usually 1600x1200x16 or 24, and almost exclusively on Trinitron 4:3 CRTs.

I just experienced this behavior with openSUSE 10.3 Beta1/post-Beta1. I did not experience this on openSUSE 10.2.
System: Lenovo ThinkPad T60p, openSUSE 10.3 Beta1 x86_64

Just to make sure: I verified once again:

X & sleep 1 && DISPLAY=:0 xterm

in the xterm

twm&
xev


Now activating xev, checking that F7 prints out the according event.
Switching to console Ctrl-Alt-F1.
Switching back to X Alt-F7.

Checking the backlog from xev in xterm. The last key events were
  Keypress Control_L
  Keypress Alt_l
  VisibilityFullyObscured
  VisbilityUnobscured
  Expose (4x)
  Keyrelease Control_L
  Keyrelease Alt_L

That's it. Nothing of F7. Just like every other test before. This is still not reproducible here.

I attached xev to firefox directly using 'xev -id 0x24000ec'.

Firefox has the focus and I'm logging xev via SSH from a second machine. 

Pressing just F7 brings up a dialog asking me if I want to toggle 'Carpet Browsing' and xev outputs:
> PropertyNotify event, serial 13, synthetic NO, window 0x24000ec,
>     atom 0xf7 (_NET_WM_USER_TIME), time 2378785059, state PropertyNewValue
> 
> FocusOut event, serial 14, synthetic NO, window 0x24000ec,
>     mode NotifyNormal, detail NotifyNonlinearVirtual
> 
> VisibilityNotify event, serial 14, synthetic NO, window 0x24000ec,
>     state VisibilityPartiallyObscured


Pressing Ctrl+Alt+F1 xev outputs:
> PropertyNotify event, serial 13, synthetic NO, window 0x24000ec,
>     atom 0xf7 (_NET_WM_USER_TIME), time 2378825003, state PropertyNewValue
> 
> PropertyNotify event, serial 14, synthetic NO, window 0x24000ec,
>     atom 0xf7 (_NET_WM_USER_TIME), time 2378825004, state PropertyNewValue
> 
> VisibilityNotify event, serial 14, synthetic NO, window 0x24000ec,
>     state VisibilityFullyObscured


And switching back via Ctrl+Alt+F7 triggers that 'Carpet Browsing' question dialog again and xev outputs:
> VisibilityNotify event, serial 14, synthetic NO, window 0x24000ec,
>     state VisibilityUnobscured
> 
> PropertyNotify event, serial 14, synthetic NO, window 0x24000ec,
>     atom 0xf7 (_NET_WM_USER_TIME), time 2378851063, state PropertyNewValue
> 
> PropertyNotify event, serial 14, synthetic NO, window 0x24000ec,
>     atom 0xf7 (_NET_WM_USER_TIME), time 2378851063, state PropertyNewValue

Not using complex environments like firefox would be more helpful. E.g. reproducing exactly the same test I did. Still, as long as nobody cannot reproduce this here...

Created attachment 175645 [details]
xev.log1

retried with opensuse 10.3 RC1
this time following exactly procedure from comment #69 :
VisibilityFullyObscured
VisibilityUnobscured
Expose
Expose
Expose
Expose
KeyRelease Control_L
KeyRelease Alt_L
KeyPress F7
KeyRelease F7
KeyPress Control_L
KeyRelease Control_L
KeyPress Alt_L
KeyRelease Alt_L

Repeated the procedure several times to be sure

so reopening

Hm. Could you please post the complete evtest log in this case? I'm especially interested in the time stamps for the Press+Release events.

the time stamps are in attachement #175645, should you need an other run, tell me.

*blush* stupid me, didn't notice the attachment.

So the keys events come within a few seconds (2, actually) after switching back, and both Press and Release events do have the same timestamp. At least one hint.

I assume you pressed the 'e' 'n' 'd' at the end of the log?


Can you please also attach the output of "evtest /dev/input/event*" (you have to select the right event device for the keyboard)? evtest is part of the input-utils package.

Created attachment 178202 [details]
log from evtest /dev/input/event0

Created attachment 178203 [details]
log from xev during evtest

this time I typed 'start' before switching to console F1, then back to xwindow and thereafter 'end'.
In evtest log 'a' is listed 'q' (my keyboard is belgian azerty) while in xev log, it's listed 'a'.

Just to mention I have "the problem" in 10.3 (upgraded from 10.2), too.

I know this is not exactly helpful, but let me summarize why this problem hasn't been solved yet:

- It only occurs outside SuSE R&D and Novell R&D
  We tried hard to reproduce, but ATM we don't know how this is triggered,
  whether it's hardware or software configuration specific, or rather depending
  on the state of the moon...

- The kernel apparently does everything correct. The evtest log looks fine.

- Most presumably the X input layer does something horribly wrong. It could
  also be KDE playing games, but somehow I doubt this.

- The X input layer is one horrible mess. If you don't believe me, watch any
  of Daniel Stone's talks.
  E.g. http://www.radeonhd.org/fosdem-2008/fosdem_2008_daniel.ogg


One hint that could help rectifying this issue:

- The Keypress/Keyrelease events have *exactly* the same timestamp.

(In reply to comment #80 from Matthias Hopf)

> - Most presumably the X input layer does something horribly wrong. It could
>   also be KDE playing games, but somehow I doubt this.

I use gnome, and I can replicate the bug. Not every time, though. It can't be something KDE specific.

Setting priority & severity according to new guidelines.

The input subsystem has changed *massively* for the Xserver shipped with 11.1.
Anybody cares to verify whether this issue is still seen with 11.1 Beta4?

Bad luck :-P

I had forgotten to report that the issue was indeed alive in Beta 3.

I'll try again next time I boot factory, if I don't forget.

There weren't any relevant changes between Beta3 and Beta4 in Xserver's input subsystem, so the issue still exits.

Yes, no need to retest with Beta 4. We didn't have any reports for 11.0, that's why I wanted to know.

In 11.0 it happens rarely to me; if I'm slow, ie, if I hold the F7 key a bit longer, it happens. But in 11.1 it happened suddenly, I was typing normally. I have only tried once... when I go back to my factory install, I'll try to remember to check for this specifically, and report back.

I finally remembered to look at this on one of my 7 Factory (beta 4) installs (Dell GX150, MGA AGP, KDE3). Still happens with Konsole [session] focused on return.

It still happens in 11.1b5.1 on my Intel 845G too.

I put both 11.0 & 11.1 with KDE3 on a new Intel G31/ICH7 with old Prescott 2.8GHz a few days ago, and neither have this problem.

Ok, if this is hardware dependent for you as well this is clearly a race condition. Unless we happen to stumble over a system here that has this issue it's almost impossible to debug, though.

(In reply to comment #91 from Matthias Hopf)
> Unless we happen to stumble over a system here that has this issue...

Maybe the following will help find something without having to trip. I spent hours today inventorying many of my systems and doing some video card swaps. What follows is a tabulation, where you can see that with Matrox the problem never fails to appear.

state	host  CPUspd  gfxchip/OS/resolution/notes
bad	A-865 3000 G550 on 10.2 1856x1392
OK	BIG31 2800 iG31 on 11.0 & 11.1 1600x1200
both	BIG31 2800 Radeon X600 on 11.0 & 11.1 1600x1200 (quickness can avoid)
both	Fi965 3400 Radeon X600 on 10.2 1600x1200 (quickness can avoid)
both	Fi965 3400 Radeon X600 on 11.0 1920x1440 (quickness can avoid)
bad	GX110 1000 i810 on 11.1b5.2 1600x1200
bad	GX150 1133 G400 on 11.1 final 1600x1200
bad	GX260 2000 i845G on 11.0 & 11.1 final 1600x1200
bad	GX270 2400 Diamond NV5 RIVA TNT2/TNT2 Pro rev11 on 11.1 final 1920x1080
OK	GX270 2400 i865G on 11.1 final 1920x1080
bad	GX270 2400 G400 on 11.1 final 1920x1080
OK	GX270 2400 Radeon 7500 on 11.1 final 1920x1080
bad	KT880 2000 Diamond NV5 RIVA TNT2/TNT2 Pro rev11 on 11.1 final 1600x1200 AMD462
bad	KT880 2000 G400 on 11.1 final 1920x1440 AMD462
bad	KT880 2000 GeForce2 MX400 on 11.1 final 1920x1440 AMD462
both	KT880 2000 Radeon 7500 on 11.1 final 1600x1200 (quickness can avoid) AMD462
bad	KT880 2000 Rage 128 on 11.1 final 1600x1200 AMD462
OK	M7NCD 2000 Radeon 7500 on 11.1 final 1600x1200 AMD462
bad	T2240 2400 i845G with 11.1b5 1600x1200

I first noticed, after well along in today's process, while doing X600 on host BIG31, that the problem seems to be in the state of the Alt key on return. It seems the trigger is mere Kup. Apparently openSUSE X since this bug was filed does not require seeing Kdn prior to Kup from within X to trigger Alt. So, whether the behavior is experienced depends on the speed of Alt key release, and whether Alt-Kup happens prior to X looking for keystrokes. Since I always release Alt after all other keys except Ctrl, there's always some delay before Alt-Kup.

A patch had been posted on the xorg ML, that *could* help with this issue. Application to our code base was difficult, though, so I'm unsure whether I have done that correctly.

Please test the server package in

  http://download.opensuse.org/repositories/home:/mhopf:/test/

(as soon as it is available).

(In reply to comment #93)
> (as soon as it is available).

Please expect some possibly considerable delay about this. I'm not easily seeing this on a daily basis since replacing my old 10.2 machine a month ago with a new one running 11.0. My testing is on hold pending completion of some more pressing things, and also I'm not doing any more Factory updates or testing until kernel-pae on factory/repo/oss is no longer stuck at 2.6.27.

I upgraded to xorg-x11-server-7.4-26.1 on opensuse 11.1 x86_64 
AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
NVIDIA GPU GeForce 6200 (NV44) at PCI:1:0:0 (GPU-0)
1600x1200

Sadly, the problem is not fixed, continue to get the "Caret Browsing" window in firefox but I have so say that with opensuse 11.1, I have to be slow (>= 1 second) with releasing the alt-F7 or ctrl-alt-F7 keys to get the problem

(In reply to comment #94)
> Please expect some possibly considerable delay about this. I'm not easily

No probs. This has been slow from our side as well. And I have to say it's just a guess, and the reactions on upstream mailing lists was... not 100% agreeable.


(In reply to comment #95)
> I upgraded to xorg-x11-server-7.4-26.1 on opensuse 11.1 x86_64

That is the one from the repo given above, right?

> Sadly, the problem is not fixed, continue to get the "Caret Browsing" window in
> firefox but I have so say that with opensuse 11.1, I have to be slow (>= 1
> second) with releasing the alt-F7 or ctrl-alt-F7 keys to get the problem

Hm, if you release the keys only one second after pressing this sounds like you get a repeat event in this case. Dunno whether this can be described as the same issue or not.

Is the behavior actually better than with the original Xserver from OS11.1, or is there no change?

Yes, that's correct repository home:mhopf:test

About the repeat event, I think you're right *but* I was using the proprietary nvidia driver from repository NVIDIA : if I hold the keys longer I get many more F7 events. No change in behavior.

So I removed the nvidia driver, and retested with the nv driver :

Now I get the "Caret Browsing" exactly once every time, even if I am as fast as I can with releasing the keys (definitively reproducible). And on the other hand, if I am very slow, there is no repeat event.
This is true with servers from both repositories openSUSE-11.1-Oss  and home:mhopf:test, so : no change in behavior.

So the patch didn't help. Sigh, too bad.

I think this can only be fixed upstream. If someone opens a bug on bugs.freedesktop.org I will point Daniel Stone (who has the most knowledge of that area in Xorg) to the bug entry.

Closing this as upstream. Still, please comment when a bug has been opened upstream. I will verify and add information if anything is missing.

(In reply to comment #98)
> I think this can only be fixed upstream.

Has anyone ever admitted being able to reproduce this on any other distro? If it can't be reproduced elsewhere, surely it cannot be an upstream issue, and any bug filed upstream would be rejected. Note that in my early comments that not only did I test on Fedora, Mandriva and Kubuntu, but that I did those tests on the very same machines.

In Cooker right now, I can switch from VT2 to VT7, not releasing the Alt key until well after all X painting has stopped, and not have the Konsole menu or Firefox caret browsing triggered. With Factory & comment 93 package on the very same machine, the function trigger usually happens even though all keys are released before anything in X paints (2000MHz P4/i845G/PS2 keyboard/Intel driver). Only when I can manage to release the keys with unnatural and extraordinary swiftness can I avoid triggering.

This particular machine I just retested with the comment 93 package is a Dell GX260 tower. Stefan Dirsch also has a GX260.

We have never been able to reproduce this here. There is a single patch regarding the input system that would point into this direction (removing a sleep(1)), which could introduce this side effect. However, the issue shows that the sleep only covered a bug that is layering deeper inside the input infrastructure.

And adding the sleep(1) again is - AFAICS - not accepted by management here. It's also the wrong solution.

But ok, you convinced me, I will try once more to reproduce, on GX260.

Ok, I was finally able to reproduce on GX260, with fbdev driver. Strange that this doesn't happen on other machines...

Created attachment 293288 [details]
Proposed fix for git xserver

AFAICS the logic for creating Release events with no key pressed is and has always been broken.

This patch seems to fix the issue. Beware that the repeat rate of the console (to be set with kbdrate) can still conflict, if you're pressing F7 too long. However, the bug itself happens without this patch even with console repeat turned off.

Created attachment 293290 [details]
Patch version for xorg-server-1.5.2

Patch version for os11.1

Guys, do you use os11.1, Factory, or os11.1 and packages from X11:XOrg ?

I have 4 11.0, 4 11.1 & 11 Factory, but most Factories have not been updated since late November due to the loss of KDE3 in Factory. IIRC only the Factory on the Dell GX260 is near current. If by X11:XOrg you mean some optional repo, I don't use it on any of them.

i386 only, or x86_64 as well? I'll build rpms for 11.1 then.

Find rpms for os11.1 i586 in http://www.suse.de/~mhopf/bug141443/ in a few minutes. Please test.

I use x86_64, so if you build for, I could test on my system

I use only 32 bit. First system I tried on I can't get Firefox to open, but the comment 107 rpms fixed the problem in Konsole 3. When I have more time I need to verify in the other 11.1 systems, maybe by Monday for at least one.

Michael, find x86_64 rpms in http://www.suse.de/~mhopf/bug141443/ now.

Felix, any updates?

The only other 11.1 I tried so far (32 bit Dell GX260) is fixed by your xorg-x11-server*-7.4-17.6. Until reviewing comment 28 I thought I was not able to reproduce (before applying those two rpms).

I tested with xorg-x11-server-7.4-17.6.x86_64.rpm and this fixes the problem while with version 7.4-26.1 it continues to happen.

Daniel Stone thinks that the patch is wrong, but unless we have a better working solution we'll use it here at SuSE. I'll open a bug upstream for Daniel.

Stefan, please apply the patch in comment #102 or comment #103 (depending on the xserver version).

Fixed in obs://X11:XOrg:sle11/xorg-x11-server and obs://X11:XOrg. Also submitted for Factory. Update for openSUSE 11.1/SLE11 will be available shortly via

  http://download.opensuse.org/repositories/X11:/XOrg:/sle11/

(build date of xorg-x11-server needs to be June 5 or later)

Committed bugs.freedesktop.org #22173:


Some users get F7 delivered to apps when switching from console to X. This only
happens when using video drivers that do a very fast switch (e.g. fbdev because
no mode switching is involved) and only on certain machines.

For a full story see Novell bug 141443 at
  https://bugzilla.novell.com/show_bug.cgi?id=141443
(yes, it is dead old, but still happens with git).

After some debugging I found the culprit in xkb/xkbPrKeyEv.c, which creates
fake KeyPress/KeyRelease events if the Key is already in the same state. For
KeyPress events this apparently was used in former times for key repeating. For
KeyRelease events I don't see a use case, it was probably coded to mirror the
KeyPress behavior.

Exactly this code hits us if a F7 release event is published, but the according
press events has not been delivered because it happened while the Xserver's VT
wasn't active.


AFAICS both Daniel and Peter concluded on the mailing list that both code paths
can be removed, because key repeat is already taken care of at a different
level nowadays.

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-PRELOAD 11-2009A (i386, x86_64)

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-PRELOAD 11-2009A (i386, x86_64)

Update released for: Mesa, Mesa-debuginfo, Mesa-debugsource, Mesa-devel, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
openSUSE 11.1 (debug, i586, ppc, ppc64, x86_64)

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debuginfo-x86, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, Mesa-x86, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debuginfo-x86, xorg-x11-driver-video-debugsource, xorg-x11-driver-video-x86, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11 (i386, x86_64)
SLE-SDK 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)