linux-kernel - Re: [RPC] OLPC tablet input driver.

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] [day] [month] [year] [list]

Message-ID: <20061108120444.GA7255@suse.cz>
Date:	Wed, 8 Nov 2006 13:04:44 +0100
From:	Vojtech Pavlik <vojtech@...e.cz>
To:	"Zephaniah E. Hull" <warp@...allh.com>
Cc:	linux-input@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [RPC] OLPC tablet input driver.

On Tue, Aug 29, 2006 at 03:33:39AM -0400, Zephaniah E. Hull wrote:

> 4: Technical/policy: Buttons are currently sent to both of the input
> devices we generate, I don't see any way to avoid this that is not a
> policy decision on which buttons belong to which device, but I'm open to
> suggestions.

I would put them on the touchpad device. This way you create a regular
looking touchpad and a regular looking tablet, and the user experience
will probably be best.

If you report them both, the GUI will get doubled click events (either
through /dev/input/mice or through the event X drivers), which can
result in doubleclicks where there were none when the click event is
very short.

So reporting on both is a bad idea.

> 5: Technical: Min/max on absolute values are currently reported as the
> protocol limits (10 bits on GS X, GS Y, and PT Y.  11 bits on PT X.  7
> bits on GS pressure).  Until we get samples based on the newer design
> and do some testing to see how big the variations are, we just don't
> have any numbers to put here.

No big deal, they're informative only. However, they're defined as the
expected min/max of what the device will report, so updating them when
you get the actual hardware running makes sense.

> 6: Technical, maybe: The early samples I have that speak this protocol
> are doing some odd things with this driver.  Mostly in the realm of
> sample rate and pressure reporting.  I'm fairly sure that this is
> hardware related, but it's worth mentioning.

I would expect the sample rate to be somewhat limited by the fact that
the packets are very large and the serial communication will not be able
to keep up.

> +	snprintf(priv->phys, sizeof(priv->phys), "%s/input1", psmouse->ps2dev.serio->phys);
> +	dev2->phys = priv->phys;
> +	dev2->name = "OLPC OLPC GlideSensor";

Why OLPC twice? Weren't you planning to say ALPS OLPC GlideSensor?

> +	dev2->id.bustype = BUS_I8042;
> +	dev2->id.vendor  = 0x0002;
> +	dev2->id.product = PSMOUSE_OLPC;
> +	dev2->id.version = 0x0000;

-- 
Vojtech Pavlik
Director SuSE Labs
-
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/