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: <20071028192031.GA11442@auslistsprd01.us.dell.com>
Date:	Sun, 28 Oct 2007 14:20:31 -0500
From:	Matt Domsch <Matt_Domsch@...l.com>
To:	"lists@...onello.org" <lists@...onello.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Dell laptop backlight driver

On Sun, Oct 28, 2007 at 07:06:23PM +0100, lists@...onello.org wrote:
> Matt Domsch wrote:
> >On Sun, Oct 28, 2007 at 05:12:37PM +0100, jack@...onello.org wrote:
> >>Hello,
> >>this driver implements backlight control on Dell laptops
> >>which use SMI  for changing brightness levels.
> >>
> >>The driver is INCOMPLETE since it is unable to probe some required 
> >>parameters
> >>in order to perform backlight control. Such parameters are found in a Dell
> >>proprietary DMI table which should be parsed. For now external tools may 
> >>be
> >>used to find these parameters by hand. So if you intend to try this out,
> >>FIRST write your laptop model parameters correctly inside the source code
> >>as explained in Documentation/dell-laptop.txt.
> >>
> >>Parts of this driver may also be used to provide additional 
> >>functionalities
> >>similarly to the drivers/misc/*-laptop.c drivers.
> >
> >Why is this better done in the kernel rather than in userspace with
> >libsmbios as you've noted?
> >
> 
> I had to do a kernelspace driver for controlling the backlight. This
> was part of a college project assignment. In order for it to be valid
> for an operating system course, it had to be in kernelspace (not
> Unix programming) :).
> 
> As i mentioned that can be done in userspace and it IS sensible to do
> so. I know that the code which was already written for Dell implied
> a userspace approach, but i simply had no choice.
> 
> I also don't expect this driver to become mainstream, but since i have
> written it, other people might want to have a look at it.

OK, that's fair.

 
> Finally i really don't think there's any sensible way of implementing
> Linux LCD Backlight Abstraction relying on a userspace application.
> That would mean the kernel calling userspace code to change the
> brightness, then this latter code would again call the kernel to trigger
> a SMI and so on. That's just not a good design. I think a userspace
> solution implies choosing NOT to implement the LCD Abstraction. Causing
> Dell laptops to be treated differently from other machines (as they are
> not compliant with Linux's own interface).

I've had this discussion on lkml before. Short story is, until Dell
laptops implement the ACPI methods that the backlight API expects, the
only sane way to do it is to let libsmbios handle it.  Moving the
fairly large and complex libsmbios into the kernel isn't a good idea
(imho).



-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ