On Mon, 17 Oct 2005 09:54:02 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Oct 2005 10:33:21 +1000 David Seikel <[EMAIL PROTECTED]> > babbled: > > > On Sun, 16 Oct 2005 12:46:27 +0200 "[EMAIL PROTECTED]" > > <[EMAIL PROTECTED]> wrote: > > > > > me hands over the 'killing it slowly monsterbug-debug-award' to > > > david > > > > For my next trick.. > > > > Although it doesn't happen often, it is occasionally annoyingly time > > consuming to have to reboot my computer when the keyboard freezes > > shortly after entranced starts up. <snip> > > I have to go and work for my bandwidth now, so I won't even start > > this process yet. Bugger, looks like today is a total write off work wise. Oh well, it's not like they pay me _much_ bandwidth. > i have seen this at some odd occasions before. the problem is - it > left me with not even being able to ctrl+alt+backspace or > ctrl+alt+f1... etc. this basically indicates the xserver itself is > not getting key presses or simply not responding to them (as x traps > these internally straight from the device and acts on them). so i > chalked it up to "crap. an x bug." and due to it being > intermittent... that was the last i bothered. That is some of the quirks I mentioned. One I have noticed is that Ctrl+Alt+F* to switch to a different VT triggers something, although not the correct thing. It starts by blanking my monitor for a few seconds. This is expected behaviour when I switch from graphics to text mode [0]. But, it then unexpectedly shows me the entrance screen again, and not the desired VT. > now if its actually an x bug, a kernel driver bug, or something else, > i don't know. but its likely some race condition i imagine related to > 2.6 kernles generic /dev/input modules, module loading, x starting up > (maybe entrance is toof ast in starting x up before modules have > finished initting) and x gets the device does its ioctl's to set the > keyboard to raw mode, then the module kicks in resetting the keyboard > into some mode it wasn't in and so the key input stream is fucked. Oh good, race conditions I am good at. B-) > thats a wild guess myself based on some zen, stab in the dark, a toss > of my lucky bones, and advice from a small 3 headed chicken i keep in > my drawer. My 3 headed chicken says hi. [0] Another pet peeve of mine. Modern monitors are slower at this than ancient monitors, and my research has shown that they are getting slower. Each new generation of monitors seems to add a large fraction of a second to mode switch time. My two year old LCD takes four seconds to switch modes, but the 11 year old CRT next to it does that in one second. It has nothing to do with the number of supported modes or frequencies as most people suspect, as my CRT supports more than my LCD does. Damn it, a modern LCD being fed a fully digital signal should not take four seconds to switch modes, that is just plain inexcusable. Fuck it, I don't have the source code for my LCD.
pgpkhYiydRNlX.pgp
Description: PGP signature
