You know you can select text with your mouse and can paste it with the third mouse button (or else). But if I select a terminal in X (or any editor) switch to a "real" console and back, then this paste command was executet. With other words I see the mouse-selected text now in my editor... Nearly a security bug: Maybe you have a root terminal and you marked "rm -rf *", then you delete the whole system... I had this bug on my old x86 and my new amd64 system. Reproducible: Always Steps to Reproduce: 1. Mark some text with your mouse (better not a command for a terminal...) 2. Open a terminal (not root) or editor, make sure your mouse-coursor is in a position to enter text 3. Switch to a "real" console (Strg-Alt-F1,...) 4. Switch back to the Xfce (not tested with kde or gnome or others...) 5. You shoul see now your marked text in step one in your editor / terminal. Expected Results: I expect that switching not execute the paste of the mouse "memory" I set this to critical, because it causes me to lose data. (with this worst case scenario: mark "rm -rf *" and switch back to a console...
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