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: <1180627767.5863.80.camel@localhost.localdomain>
Date:	Thu, 31 May 2007 17:09:26 +0100
From:	Richard Purdie <rpurdie@...ys.net>
To:	Jan Kratochvil <honza@...os.cz>
Cc:	Pavel Machek <pavel@....cz>, dtor@...l.ru,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Support for controlling leds on xbox 360 pad.

Hi,

On Thu, 2007-05-31 at 17:53 +0200, Jan Kratochvil wrote:
> On Thu, 31 May 2007, Pavel Machek wrote:
> >> Led subsystem allows us to set brightness, but there is
> >> nothing like brightness on this device. So brightness is
> >> actually interpreted as the command (only values between
> >> 0 and 14 are accepted).
> >
> > Ugh, no, I do not think we want to do that.
> 
> finally! I was surprised that it took so long before someone made objection to 
> this.

:)

This hadn't gone unnoticed by me and I didn't like it either at first
however I had a look at the hardware specs and your summary below is
pretty accurate...

> I agree that interpreting brightness as command isn't nice. But what other 
> options do I have?
>   a) Do not use led subystem, and do everything on my own
>   b) Do not allow user to change state of leds on this device
>   c) Extend led subsystem to have something like command. But it is in 
> contradiction with desired simplicity of led sybsystem.

Since the commands are so device specific and no new device will be the
same, I doubt this is worth doing (or possible) in a generic way so
you're back to a).

>   d) Control leds via force feedback effect
>   e) Make 4 leds available and use brightness 0 for off and 255 for on. But only 
> one of them can be active at one time. And I'll give up some flashing effects.

If you expose 4 leds, you break the API badly as only one can be active.
That is worse than using the brightness parameter IMO.

> Well actually I don't like this options. Any suggestions? Thanks!

After consideration, I agree with your approach of using the brightness
and I don't have a better suggestion. Its not ideal but its a good
compromise since it doesn't really impose any limitations on your use of
the hardware but doesn't need a custom implementation which is the
alternative. The mode is still a kind of brightness setting if you twist
the definition a bit ;-).

Cheers,

Richard


-
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