linux-kernel - Re: [PATCH] Map volume and brightness events on thinkpads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071016184606.GB25181@srcf.ucam.org>
Date:	Tue, 16 Oct 2007 19:46:06 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Jeremy Katz <katzj@...hat.com>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, davej@...hat.com,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH] Map volume and brightness events on thinkpads

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 | mjg59@...f.ucam.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/