Am Dienstag, den 03.03.2009, 00:53 +0100 schrieb Nils Faerber: > Michael 'Mickey' Lauer schrieb: > > Am Dienstag, den 03.03.2009, 00:36 +0100 schrieb Nils Faerber: > >>> I agree and I'd love to see that as well. It's a ... drum-roll... kernel > >>> thing :) At some time in kernel 2.5 the console suspend/resume code > >>> gained the infamous property to change to a dedicated VT where the > >>> suspend/resume progress gets output. Garmin once released sources for > >>> one of their Linux-based PMN devices where they patches this away -- > >>> perhaps you find this or can patch it out on your own. We'd be > >>> interested. > >> OK, I can confirm now that the VT switch disappears with the kernel > >> config change I posted earlier. > >> Though of course this also eliminates the kernel startup messages on the > >> screen. But well, they are flying by that fast that I doubt anyone is > >> really able to read them. Suspend/resume is much faster now. > > That sounds pretty cool, although it means we also have to give up on > > the VT consoles at all, which is not quite what I had in mind. > > > > Can't we just have the VT consoles without the switching on > > suspend/resume? > > The VT terminals are still there, just not the console.
Sure, but I really mean the console. I have systems with hardware keyboards where the VT console with a login prompt comes in handy. > > Of course we could also introduce a new kernel config option for just > disabling the console suspend but that would mean a real kernel patch. Don't be shy ;) > As you like, I can surely also create such a new kernel config option - > should be pretty easy but brings the kernel a bit more away from mainline. I don't think that's a problem. First, I think it's a patch that would be welcome upstream, since all Linux-based polished devices have to worry about that. Second, have a look how many custom patches we carry in andy-tracking... one more won't hurt ;) > BTW: Could you briefly explain the battery class problem? Probably I can > fix that too... mwester did a power class supply driver for the GTA01's dumb batteries once -- I'm not sure whether this needs adjusting for 2.6.28. To make it more complicated, GTA02 can work with both the new ones (for which we have a power class supply driver), but also with the old ones. Since GTA02 has a different PMU, we need a completely different driver for GTA01's dumb batteries in GTA02. I don't know whether mike is still interested in working on that. -- :M: _______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
