On Tue, Oct 16, 2007 at 02:56:23PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > They're keys that generate scancodes through the keyboard controller.
>
> The fact is that we were not used to anything using the keyboard controller
> as a message-passing device, but nowadays that is (unfortunately) happening.
>
> It still doesn't mean it belongs inside the stream of data for the keyboard,
> maskerading as a key press.
But it *is* a key press!
> > There's no advantage in having to implement multiple solutions. If we're
> > stuck with one of them, we might as well just use it for the other cases
> > as well.
>
> IMO we might as well go to the clean road, deploy a generic interface that
> CAN do it properly (might as well be input, but Dmitry has some good reasons
> not to want it there), and move to it.
I think Dmitry is wrong here. Input is the right layer for sending
keypress information to userland.
> > No, these aren't ACPI keys and the machines don't provide backlight
> > control through ACPI. It's not a problem with more recent Dells, but
> > machines before mid-2006 or so have this issue.
>
> Am I the only one seeing the irony on that comment over the idea of sending
> such events through the input layer? ACPI is not just a way to talk to AML
> crap in the BIOS. Is a (somewhat obtuse, very limited) generic interface to
> model the hardware. But for backlight, it certianly is powerful enough.
Well, yes, we could have a layer in the kernel to turn the key events
into ACPI events and then let the video module turn them back into input
events, but that still wouldn't deal with the fact that legacy Dell
backlight control isn't going to happen in the kernel.
Anyway. My point was that saying we shouldn't put notification events
through the input layer is at odds with reality - we already do, and
they already arrive with EV_KEY. Userspace copes. Who benefits from
doing it in any other way? Userspace doesn't - we'd need to rewrite
parts of it to deal with the new setup. The kernel doesn't, because it
doesn't consume these events itself. Coming up with a "cleaner"
interface just results in more work for everyone. We should just go with
the defacto standard, especially since it's one that's been implemented
by various hardware vendors.
--
Matthew Garrett | [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
