Re: Possible Solution for Frequent Keyboard Hangups in KDE.
On Fri, Sep 14, 2012, Shlomi Fish wrote about Possible Solution for Frequent Keyboard Hangups in KDE.: Hi all, in case you are experiencing cases where the keyboard in KDE become unresponsive sometimes, then I have discovered a way to predictably reproduce this hang-up, and to avoid it. See this KDE bug here: Sadly, this is a much bigger problem than you describe, which has plagued various distributions for the last year: People have been reporting - and it also repeatedly happened to me personally - that X Windows's keyboard hangs while the rest of the computer (as well as the mouse) continues to work normally. To some people, this hang happened several times a week, bringing Linux's reliability close to that of 1990s MS Windows :( Further investigation revealed that the keyboard is NOT actually hung, but rather in a little-known state called SlowKeys - if you press a key for over a second, it *will* be accepted. If you care enough, you can actually type something in this weird state. But clearly this state was meant for people with very specific disabilities - and not for the general population. So how and why is does one randomly get into this state? Continuing the investigation, you'll discover that when X is in a new and little-known state called AccessX, it enables the dreaded SlowKeys mode when you press the shift key for 10 seconds. Yes, that's right - if you daydream with your hand on the shift, bye bye keyboard. So, you might be asking, why is this AccessX state even turned on by default? Apparently, it *shouldn't*. X does *not* turn it on by default. But various buggy Gnome and KDE crap do. On my Fedora, it is GDM (the Gnome login screen - which is used even if you end up running KDE) which turns it on (apparently to help people with disabilities to log in) but forgets to turn it back off when it starts the session. Various window managers also turn this feature on - it should be off by default unless the user chooses this feature, but apparently (as I can see from various bug reports in Fedora) most window managers got this wrong in some way or another. For the GDM bug (which I described above) is probably causing the problem for most users. My solution was to install a utility called xkbset which knows about these new X features, and turn them off. xkbset -a turns off AccessX, which turns off that terrible press-shift-for-10-seconds-and-your-keyboard-is-toast feature. I run this xkbset -a as part of the session startup, and haven't had a keyboard hang since. -- Nadav Har'El|Sunday, Sep 16 2012, 29 Elul 5772 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |A facility for quotation covers the http://nadav.harel.org.il |absence of original thought. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Possible Solution for Frequent Keyboard Hangups in KDE.
On Sun, Sep 16, 2012 at 9:14 AM, Nadav Har'El n...@math.technion.ac.il wrote: But various buggy Gnome and KDE crap do. On my Fedora, it is GDM (the Gnome login screen - which is used even if you end up running KDE) which turns it on (apparently to help people with disabilities to log in) but forgets to turn it back off when it starts the session. I have never experienced this bug (on Fedora or RHEL), probably for one of two reasons: 1) I don't enable - or install - the disabilities-related functionality (this does not mean that related bugs should not be fixed, of course...) 2) I use KDE rather than GNOME. The default login manager remains GDM though unless you do # cat /etc/sysconfig/desktop DISPLAYMANAGER=KDE ^D # - check /etc/X11/prefdm to see what it does. Of course you can use KDM for login and still run GNOME as your desktop, maybe it helps with this particular problem (if the culprit is GDM). -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Possible Solution for Frequent Keyboard Hangups in KDE.
Hi Nadav,
On Sun, Sep 16, 2012 at 09:14:00AM +0300, Nadav Har'El wrote:
On Fri, Sep 14, 2012, Shlomi Fish wrote about Possible Solution for Frequent
Keyboard Hangups in KDE.:
Hi all,
in case you are experiencing cases where the keyboard in KDE become
unresponsive sometimes, then I have discovered a way to predictably
reproduce this hang-up, and to avoid it. See this KDE bug here:
Sadly, this is a much bigger problem than you describe, which has
plagued various distributions for the last year: People have been reporting -
and it also repeatedly happened to me personally - that X Windows's
keyboard hangs while the rest of the computer (as well as the mouse)
continues to work normally. To some people, this hang happened several
times a week, bringing Linux's reliability close to that of 1990s MS
Windows :(
Further investigation revealed that the keyboard is NOT actually hung,
but rather in a little-known state called SlowKeys - if you press a
key for over a second, it *will* be accepted. If you care enough, you can
actually type something in this weird state. But clearly this state was
meant for people with very specific disabilities - and not for the
general population. So how and why is does one randomly get into this
state?
Continuing the investigation, you'll discover that when X is in a new
and little-known state called AccessX, it enables the dreaded
SlowKeys mode when you press the shift key for 10 seconds. Yes, that's
right - if you daydream with your hand on the shift, bye bye keyboard.
I just wanted to note that for me, at least, another 10 seconds Shift key
press toggles the keyboard to its normal non-SlowKeys state.
So, you might be asking, why is this AccessX state even turned on by
default? Apparently, it *shouldn't*. X does *not* turn it on by default.
But various buggy Gnome and KDE crap do. On my Fedora, it is GDM (the Gnome
login screen - which is used even if you end up running KDE) which turns it
on (apparently to help people with disabilities to log in) but forgets to
turn it back off when it starts the session. Various window managers also
turn this feature on - it should be off by default unless the user chooses
this feature, but apparently (as I can see from various bug reports in Fedora)
most window managers got this wrong in some way or another. For the GDM
bug (which I described above) is probably causing the problem for most users.
My solution was to install a utility called xkbset which knows about
these new X features, and turn them off. xkbset -a turns off AccessX,
which turns off that terrible
press-shift-for-10-seconds-and-your-keyboard-is-toast feature.
I run this xkbset -a as part of the session startup, and haven't had a
keyboard hang since.
Tanks for the tip. Adding to my ~/.xsession script.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Possible Solution for Frequent Keyboard Hangups in KDE.
On Sun, Sep 16, 2012, Oleg Goldshmidt wrote about Re: Possible Solution for Frequent Keyboard Hangups in KDE.: I have never experienced this bug (on Fedora or RHEL), probably for one of two reasons: 1) I don't enable - or install - the disabilities-related functionality (this does not mean that related bugs should not be fixed, of course...) I also never intentially installed or enabled any disability related functionality. The problem is that the modern philosophy shared by GNOME/KDE/Fedora/Ubuntu is that they don't really care what the user wants to configure. The user is stupid, so the OS should control him, not the other way around. If it worked for MS-Windows and Apple iOS, why wouldn't it work for them? :( 2) I use KDE rather than GNOME. The default login manager remains GDM though unless you do # cat /etc/sysconfig/desktop DISPLAYMANAGER=KDE So did you actually do that? I not only *not* use Gnome, I also don't use KDE (I use a completely home-brewed environment based on the archaic^H^H^H^H^H^H^Hclassic window manager ctwm). But I was still using GDM for the login, so its bug of leaving the accessx mode enabled still effected me. Try pressing the (left?) shift for more than 10 seconds, and see if you really don't have this bug, or you were just lucky enough never to press the shift key for so long. Like I said, this happened to just once every few days - it's not a very common occurance. - check /etc/X11/prefdm to see what it does. Of course you can use KDM for login and still run GNOME as your desktop, maybe it helps with this particular problem (if the culprit is GDM). Right, although I have no quibbles with GDM, I just wish they fixed its accessx bit (and once I found that running xkbset -a removes this bit, I no longer personally care if this bug exists). Anyway, like I said, while GDM was the cause of the bug for me, I understood that other people see a similar bug caused by other sources. -- Nadav Har'El|Sunday, Sep 16 2012, 29 Elul 5772 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |My password is my dog's name. His name is http://nadav.harel.org.il |a#j!4@h, but I change it every month. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Possible Solution for Frequent Keyboard Hangups in KDE.
On Sun, Sep 16, 2012, Baruch Siach wrote about Re: Possible Solution for Frequent Keyboard Hangups in KDE.: Continuing the investigation, you'll discover that when X is in a new and little-known state called AccessX, it enables the dreaded SlowKeys mode when you press the shift key for 10 seconds. Yes, that's right - if you daydream with your hand on the shift, bye bye keyboard. I just wanted to note that for me, at least, another 10 seconds Shift key press toggles the keyboard to its normal non-SlowKeys state. Everyone says that, but strangely, I was never able to disable the SlowKeys mode in this way... Once I accidentally turned it on, I had no way to turn it off but slowly slowly typing xkbset -sl. I don't know why on my setup, a 10 second shift for the second time does not turn it off. But anyway, frankly, before I started to investigate this issue, there is no way I could have even guessed that a 10 second shift would solve this problem. It took me several months (!) to even figure out that the hangs I experienced were caused by pressing the shift for 10 seconds. -- Nadav Har'El|Sunday, Sep 16 2012, 29 Elul 5772 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Attention: There will be a rain dance http://nadav.harel.org.il |Friday night, weather permitting. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Possible Solution for Frequent Keyboard Hangups in KDE.
Nadav Har'El n...@math.technion.ac.il writes: I also never intentially installed or enabled any disability related functionality. The problem is that the modern philosophy shared by GNOME/KDE/Fedora/Ubuntu is that they don't really care what the user wants to configure. I guess I am lucky because for a variety of reasons that are not worth going into none of the default installation options fits my needs so I always choose custom and pick what I install. I wasn't even aware of this problem before this thread. # cat /etc/sysconfig/desktop DISPLAYMANAGER=KDE So did you actually do that? Yes. Always. For a completely unrelated reason though. I only mentioned that because you seemed to imply that the bug was in GDM, which is the default login manager. Try pressing the (left?) shift for more than 10 seconds, and see if you really don't have this bug, No, thanks, not before I actually find this xkbset thingy: yum whatprovides */xkbset returns no matches. or you were just lucky enough never to press the shift key for so long. Possibly. Stories abound of fun stuff happening when a notebook is accidentally left on a keyboard... ;-) Shana Tova to all! -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
introduction to exploit for newbie
hey guys, I gave a free speech about basic exploit and crackme 101 on GNU/Linux at Beijing GNU/Linux User Group earlier this week. The slide[1] and video demo[2] were all uploaded. You guys might have interesting about it. [1] slide http://hfg-resources.googlecode.com/files/blug-exp.pdf [2] demo http://hfg-resources.googlecode.com/files/blug-exp-demo.avi -- GNU powered it... GPL protect it... God blessing it... regards Shawn ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
introduction to exploit for newbie
hey guys, I gave a free speech about basic exploit and crackme 101 on GNU/Linux at Beijing GNU/Linux User Group earlier this week. The slide[1] and video demo[2] were all uploaded. You guys might have interesting about it. [1] slide http://hfg-resources.googlecode.com/files/blug-exp.pdf [2] demo http://hfg-resources.googlecode.com/files/blug-exp-demo.avi -- GNU powered it... GPL protect it... God blessing it... regards Shawn ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: introduction to exploit for newbie
hey Steve, I checked my clock setting that is correct. Maybe some mail server got some problem! On Mon, Sep 17, 2012 at 3:14 AM, Steve Litt sl...@troubleshooters.com wrote: Hi Shawn, You've sent me several cool resources today. Thanks. Could you please fix your system clock? One of your emails today was dated in 2011, and the other two were dated three days ago. In Claws-Mail, out-of-date new emails take finite time to track down. Thanks SteveT Steve Litt* http://www.troubleshooters.com/ * http://twitter.com/stevelitt Troubleshooting Training * Human Performance -- GNU powered it... GPL protect it... God blessing it... regards Shawn ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
