linux-kernel - Re: [PATCH] Logitech G13 driver (fixed cc list --- ignore others)

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: <7f9100aac5f9b06ec78efff25c7a5a71.squirrel@intranet.cs.nmsu.edu>
Date:	Mon, 4 Jan 2010 15:23:36 -0700
From:	"Rick L. Vinyard, Jr." <rvinyard@...nmsu.edu>
To:	"Jiri Kosina" <jkosina@...e.cz>
Cc:	"Pavel Machek" <pavel@....cz>, linux-kernel@...r.kernel.org,
	krzysztof.h1@...pl, "Andrew Morton" <akpm@...ux-foundation.org>,
	linux-usb@...r.kernel.org, "Oliver Neukum" <oliver@...kum.org>,
	linux-input@...r.kernel.org
Subject: Re: [PATCH] Logitech G13 driver (fixed cc list --- ignore others)

Jiri Kosina wrote:
> On Wed, 16 Dec 2009, Pavel Machek wrote:
>
>> > Although identified as a HID, the device does not support standard HID
>> > input messages. As a result, a sub-input device is allocated and
>> > registered separately in g13_probe(). The raw events are monitored and
>> > key presses/joystick activity is reported through the input device
>> > after referencing an indexed keymap.
>> >
>> > Additionally, this device contains a 160x43 monochrome LCD display. A
>> > registered framebuffer device manages this display. The design of this
>> > portion of the driver was based on the design of the hecubafb driver
>> > with deferred framebuffer I/O since there is no real memory to map.
>> >
>> > This patch is against the torvalds/linux-2.6.git tree.
>>
>> Should this use auxdisplay framework and be located there?
>
> Well, the device is still primarily HID device in its nature, so either
> keeping the whole driver in drivers/hid, or separating it into two
> drivers, one for the HID part and second for the framebuffer part should
> be acceptable.

The framebuffer part uses the same interrupt endpoint for both HID and
display. IIRC there were issues with two drivers using the same interrupt
endpoint.


>
>> > --- /dev/null
>> > +++ b/drivers/hid/hid-g13-logo.xbm
>> > @@ -0,0 +1,75 @@
>> > +#define g13_lcd_width 160
>> > +#define g13_lcd_height 43
>> > +static unsigned char g13_lcd_bits[] = {
>> > +   0x00, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> 0x00,
>> > +   0x00, 0x00, 0x00, 0x28, 0x03, 0x00, 0x40, 0x01, 0x00, 0xc0, 0x3f,
>> 0x00,
>> > +   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> 0xa1,
>> > +   0x08, 0x00, 0x08, 0x00, 0x00, 0xe0, 0x7f, 0x00, 0x00, 0x00,
>> > 0x00, 0x00,
>>
>> I'd prefer to go without another logo. Just make sure default penguin
>> gets
>> there or something.
>
> What logo is this, BTW? :)
>

It's similar to the default G13 load image, but with tux on the left and
the GNU gnu on the right.

I tried to particularly clean up tux a bit since the default monochrome
logo is 80x80 and the display is 160x43.

The only alternatives I could think of were to use the default logo and
load it at 80x43 which cuts off Tux at the nipples, resample in the
driver, or leave the logo off.

I didn't like the first because it didn't look like tux without his belly
and feet, the second seemed overly complex, and the third doesn't provide
a visual cue to the user that it's plugged in and all is well.

The visual cue is particularly necessary because the device displays a G13
logo on initialization even when no working driver is present. It's
problematic because it appears as if the device is ready, so the use of a
penguin provides a Linux specific cue.

> I will proceed with reviewing the driver soon, sorry for slightly higher
> latencies these days.
>

No problem... as you can see my latency responding is rather high.


--
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/