Summary: | x11-drivers/xf86-input-mouse: switch to console and back makes X paste clipboard contents in foreground window | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan Buecken <jb.faq> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | galtgendo, jer |
Priority: | High | Keywords: | STABLEREQ |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 251832 | ||
Bug Blocks: | |||
Attachments: |
xev cut-off from terminal
xev > xev.txt |
Description
Jan Buecken
2008-09-29 13:57:38 UTC
What key combination do you use to return to the X terminal? Hi there, I use: Alt-F7 And this doesn't happen without xfce-base/xfce4-4.4.2, like with a completely different window manager or a different version of xfce? I installed kde 3.5.9. (sry, this take some time on gentoo ;-) ) This problem holds with this windows manager. And it occurs in the "failsafe terminal". Ok, this is not only a xfce problem. Doesn't try another version of xfce beacause there is no ebuild in the protage (Yes I know, I can look here or write it myself, but I do it only if necessary) and gnome want to install to many software... Hint: I don't think its a driver problem with my ati card because my old system had a nvidia card... In both cases I use the propritary driver. The fraembuffer driver is on both systems uvesafb, I don't know if this is relevant. It's more likely to be a problem with the server itself or with the input driver. I have a similar problem (xorg-server-1.5.1 and xf86-input-evdev). While it doesn't paste anything for me, it sends Fn to the terminal, when switching with Alt-Ctrl-Fn. Ok, then its time to offer more information: I use a laptop / notebook. German keyboard layout: ************************* Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "CoreKeyboard" Option "XkbModel" "pc105" Option "XkbRules" "xorg" Option "XkbLayout" "de" # Option "XkbVariant" "nodeadkeys" ************************* I use xorg-server-1.4.2 xf86-input-keyboard-1.3.0 xf86-input-mouse-1.2.3 and xf86-input-evdev is not installed! OK, so having a German layout, do you happen to use AltGr-F7 (as opposed to Alt-F7) to switch consoles? I use XkbVariant "nodeadkeys" now. Probmel holds. With AltGr-F7 I cannot switch consoles. Nothing happens (only in X, but thats normal...). You ask all this, do you have any idea of a direction where the failure is? Could you check if you can reproduce it with evdev driver (cause the problem is probably somewhere between input driver and the server) ? (In reply to comment #8) > I use XkbVariant "nodeadkeys" now. Probmel holds. With AltGr-F7 I cannot > switch consoles. Nothing happens (only in X, but thats normal...). Could you run xev (x11-apps/xev) in X in the foreground and then do the console switch? > You ask all this, do you have any idea of a direction where the failure is? Certainly. :) Created attachment 167094 [details]
xev cut-off from terminal
First test: started xev, switched to console and back to X. Interesting:
It seems to me the paste was not catched: "inux@Targa1526" was the marked text and was paste in the terminal.
Hint: I had to copy this from the console, hence it is only a cut-off.
Created attachment 167095 [details]
xev > xev.txt
Same procedure, but now with "xev > xev.txt".
The problem is that I have to stop xev with moving mouse and "Ctrl-C". Hence the last entries are not from switching. Don't know to find out which is the right.
The test with evdev needs some time (had some problems with it, X Server did not want to start) and now I have to leave my internet and go to a habitation without internet for the weekend :-( ...
I don't test evdev yet, but I found this: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/276887 Fixed with evdev 2.0.6 I believe it could be a bug in xf86-input-keyboard/mouse, similar to the evdev bug... Now I try to update xf86-input-keyboard to 1.3.1 and -mouse to 1.3.0 Then I try updating X with and use newest evdev (in portage, 2.0.5). If the bug says: "fixed in 2.0.6" why do you think 2.0.5 will make a difference ? Thanks, now we can finally put a package and maintainer to this problem! :) (In reply to comment #15) > Thanks, now we can finally put a package and maintainer to this problem! :) > NO! I said I DON'T use evdev, it is not installed at all! I only want to make clear there was a similar problem. And as I read, it is NOT exactly the same bug (I don't need to type anything on the console and so on). Maybe the developers make similar mistakes... Because of this I think: If I test evdev-2.0.5 and I have not exactly(!) the same bug (or I can test 2.0.6, but it is not in portage yet), then xf86-input-keyboard/mouse has the bug. *sigh* x11-drivers/xf86-input-mouse is the right package! Reason: Update keyboard to 1.3.1 and mouse to 1.3.0: bug fixed! Downgrade back the mouse driver to 1.2.3: bug is there! Update mouse back to 1.3.0 and downgrade keyboard back to 1.3.0: bug fixed! It follows the input-mouse driver was affected. Now its your turn Jeroen, you can post your commit 15 again ;-) Hi, I use x11-drivers/xf86-input-mouse-1.3.0 and keyboard-1.3.0 since 6 days on amd64 with no problems. Voting for unkeywording (of both) in portage because of the bug in mouse-1.2.3 and then closing this bug. Stabilization is getting closer, this bug should be fixed when 1.5.3-r2 and friends hit the stable tree. Thanks 1.5.3-r5 is now stable, closing. Thanks |