On Thu, 12 Jul 2007, Pavel Machek wrote:
> I'm not sure what you mean here. Should the code be moved to atkbd.c?
> ...and then duplicated to usbkbd.c?
Hi Pavel,
just a sidenote - usbkbd.c is probably a confusing misnomer, renaming it
to something more appropriate is on my todo for one day. It
Hi!
> > > I'll take patches. Ofcourse we'll have to keep the current EV_LED
> > > interface
> > > for compatibility.
> >
> > Here's a working version. For some reason, it only works with capslock
> > led. (But so does your code, is that thinkpad problem?)
>
> My code does blink NumLock on my bo
Pavel Machek wrote:
...drivers are not expected to act on their own. I was expecting to
get nice /sys/class/led* interface to my keyboard leds.
What's the benefit of such an interface? If you're able to trigger
keyboard LEDs via that interface, you're also able to use the ioctl()
on /dev/consol
On Wednesday 04 July 2007 18:11, Pavel Machek wrote:
> Hi!
>
> > > > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > > > solve the "video output dead after kexec; but need visual feedback
> > > > > > to the user
> > > > > > while crash dumping" problem. I'm waitin
On Wednesday 04 July 2007 17:47, Pavel Machek wrote:
> Hi!
>
> > >I was thinking about something like the atached (untested and sorry
> > >for using attachment). It shoudl blink just one led (numLock) on any
> > >keyboard that has such LED (and allows to control it).
> > >
> >
> > Argh, bad one.
Hi!
> > I copied code from Dmitry :-); guess I copied too much. Here's updated
> > version:
>
> Umm, it's updated exactly how?
Sorry. I updated it in my tree but produced wrong patch. Here's
updated updated version: (trimmed cc list).
> > +struct blinker {
> > + struct delayed_work work;
> ..
Hi!
> > Actually here's one that does not immediately oops when I plug USB
> > keyboard in.
>
> Why do you use a delayed workqueue and then always use it without a delay?
> That seems silly.
I copied code from Dmitry :-); guess I copied too much. Here's updated
version:
Signed-off-by: Pavel Ma
On Thu, 5 Jul 2007, Pavel Machek wrote:
>
> Actually here's one that does not immediately oops when I plug USB
> keyboard in.
Why do you use a delayed workqueue and then always use it without a delay?
That seems silly.
Linus
-
To unsubscribe from this list: send the line "unsub
Hi!
> > tristate "Keyboard blink driver"
> >
> > ...drivers are not expected to act on their own. I was expecting to
> > get nice /sys/class/led* interface to my keyboard leds.
> >
> > BTW ... I still believe we should have /sys/class/led* interface to
> > those leds. I'd like to make them blink
Hi!
> > > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > > solve the "video output dead after kexec; but need visual feedback to
> > > > > the user
> > > > > while crash dumping" problem. I'm waiting for your patches.
> > > > >
> > > >
> > > > I don't don't like
On Tue 2007-07-03 01:42:35, Dmitry Torokhov wrote:
> On Monday 02 July 2007 19:08, Pavel Machek wrote:
> > On Mon 2007-07-02 14:39:27, Andi Kleen wrote:
> > >
> > > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > > solve the "video output dead after kexec; but need
Hi!
> >I was thinking about something like the atached (untested and sorry
> >for using attachment). It shoudl blink just one led (numLock) on any
> >keyboard that has such LED (and allows to control it).
> >
>
> Argh, bad one. This one shoudl be better.
Does it blink for you? It does not seem t
Hi!
> > > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > > solve the "video output dead after kexec; but need visual feedback to
> > > > > the user
> > > > > while crash dumping" problem. I'm waiting for your patches.
> > > > >
> > > >
> > > > I don't don't like
Hi!
> > > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > > solve the "video output dead after kexec; but need visual feedback to
> > > > > the user
> > > > > while crash dumping" problem. I'm waiting for your patches.
> > > > >
> > > >
> > > > I don't don't like
* Pavel Machek <[EMAIL PROTECTED]> [2007-07-03 01:08]:
> On Mon 2007-07-02 14:39:27, Andi Kleen wrote:
> >
> > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > solve the "video output dead after kexec; but need visual feedback to
> > > > the user
> > > > while cras
On Monday 02 July 2007 19:08, Pavel Machek wrote:
> On Mon 2007-07-02 14:39:27, Andi Kleen wrote:
> >
> > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > solve the "video output dead after kexec; but need visual feedback to
> > > > the user
> > > > while crash dum
Hi!
> > The patch makes sense. You don't need to poll every jiffie to find
> > out if system has panic.
>
> The blink driver doesn't run on panic (or at least not on panic on
> the same kernel). It runs always. It was designed to do the blinking
> while the kdump kernel runs and writes the dump.
On Mon 2007-07-02 14:39:27, Andi Kleen wrote:
>
> > > Perhaps one of you geniuses who all hate it can find a better way to
> > > solve the "video output dead after kexec; but need visual feedback to the
> > > user
> > > while crash dumping" problem. I'm waiting for your patches.
> > >
> >
> > I
* Dmitry Torokhov <[EMAIL PROTECTED]> [2007-07-02 15:43]:
> On 7/2/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
>>
>> I was thinking about something like the atached (untested and sorry
>> for using attachment). It shoudl blink just one led (numLock) on any
>> keyboard that has such LED (and allo
On Monday 02 July 2007 19:50:00 Stephen Hemminger wrote:
> The patch makes sense. You don't need to poll every jiffie to find
> out if system has panic.
The blink driver doesn't run on panic (or at least not on panic on
the same kernel). It runs always. It was designed to do the blinking
while th
On 7/2/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
The patch makes sense. You don't need to poll every jiffie to find
out if system has panic. But I agree with Linus, it is the kind
of patch that doesn't belong in the mainline kernel. Every developer
seems to have built up a set of crappy
On Mon, 2 Jul 2007 01:59:50 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Monday 02 July 2007 00:14, Linus Torvalds wrote:
> > On Sun, 1 Jul 2007, Andi Kleen wrote:
> > > What is so bad with it? Note it's a debugging facility and used
> > > for kcrash kernels where the video output doesn't work
> > Anyways, Stephen's patch just doesn't make sense:
> > he clearly didn't understand the code at all. Before you
> > apply it and cripple it better drop the driver completely.
>
> I think I will have to.
Make it depend on the kernel debug options and if you are really paranoid
also add a modul
On Mon, 2 Jul 2007, Andi Kleen wrote:
>
> It's not intended for normal kernels. It's a debugging feature.
> It's not intended for normal kernels. It's a debugging feature.
> It's not intended for normal kernels. It's a debugging feature.
>
> Got it now?
You seem to have some reading comprehensi
On 7/2/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
I was thinking about something like the atached (untested and sorry
for using attachment). It shoudl blink just one led (numLock) on any
keyboard that has such LED (and allows to control it).
Argh, bad one. This one shoudl be better.
--
D
On 7/2/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Perhaps one of you geniuses who all hate it can find a better way to
> > solve the "video output dead after kexec; but need visual feedback to the
user
> > while crash dumping" problem. I'm waiting for your patches.
> >
>
> I don't don't like
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Monday 02 July 2007 00:14, Linus Torvalds wrote:
>> On Sun, 1 Jul 2007, Andi Kleen wrote:
>> > What is so bad with it? Note it's a debugging facility and used
>> > for kcrash kernels where the video output doesn't work. But they
>> > normally only run a f
* Andi Kleen <[EMAIL PROTECTED]> [2007-07-02 14:39]:
>
> > Another option would be for it not use panic_blink. Do your kexec
> > kernels have atkbd support enabled? You could write an new "blink"
> > input handler that would latch to keyboards supporting leds and blink
> > by sending EV_LED events
> > Perhaps one of you geniuses who all hate it can find a better way to
> > solve the "video output dead after kexec; but need visual feedback to the
> > user
> > while crash dumping" problem. I'm waiting for your patches.
> >
>
> I don't don't like it ;) Unfortunately too many people end up en
On 7/2/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Monday 02 July 2007 13:43:23 Indan Zupancic wrote:
> On Mon, July 2, 2007 01:59, Andi Kleen wrote:
> > Well only those that could be already hung from user space
> > with setleds (that was also confirmed). Actually I thought
> > they didn't han
On Mon, July 2, 2007 13:51, Andi Kleen wrote:
> On Monday 02 July 2007 13:43:23 Indan Zupancic wrote:
>> On Mon, July 2, 2007 01:59, Andi Kleen wrote:
>> > Well only those that could be already hung from user space
>> > with setleds (that was also confirmed). Actually I thought
>> > they didn't ha
On Monday 02 July 2007 13:43:23 Indan Zupancic wrote:
> On Mon, July 2, 2007 01:59, Andi Kleen wrote:
> > Well only those that could be already hung from user space
> > with setleds (that was also confirmed). Actually I thought
> > they didn't hang completely, but just stopped reacting to
> > the
On Mon, July 2, 2007 01:59, Andi Kleen wrote:
> Well only those that could be already hung from user space
> with setleds (that was also confirmed). Actually I thought
> they didn't hang completely, but just stopped reacting to
> the keyboard (which is actually pretty bad for every user
> to be ab
On Monday 02 July 2007 00:14, Linus Torvalds wrote:
> On Sun, 1 Jul 2007, Andi Kleen wrote:
> > What is so bad with it? Note it's a debugging facility and used
> > for kcrash kernels where the video output doesn't work. But they
> > normally only run a few minutes to dump the previous state to disk
On Sun, 1 Jul 2007, Andi Kleen wrote:
>
> What is so bad with it? Note it's a debugging facility and used
> for kcrash kernels where the video output doesn't work. But they
> normally only run a few minutes to dump the previous state to disk
> and then reboot.
It has been a total disaster fro
On Sunday 01 July 2007 20:07:21 Linus Torvalds wrote:
>
> On Sun, 1 Jul 2007, Stephen Hemminger wrote:
> >
> > The blink driver wakes up every jiffies which wastes power unnecessarily.
> > Using a notifier gives same effect. Also add ability to unload module.
>
> I really get the feeling this thi
On Sunday 01 July 2007 18:50:35 Stephen Hemminger wrote:
> The blink driver wakes up every jiffies which wastes power unnecessarily.
> Using a notifier gives same effect. Also add ability to unload module.
It's really a debugging tool where you normally don't care about
details like this. I wrote
On Sun, 1 Jul 2007, Stephen Hemminger wrote:
>
> The blink driver wakes up every jiffies which wastes power unnecessarily.
> Using a notifier gives same effect. Also add ability to unload module.
I really get the feeling this thing should be removed entirely. Wasting
power is the _least_ of its
38 matches
Mail list logo
