linux-kernel - Re: [eBeam PATCH 2/2] input: misc: New USB eBeam 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5047AECE.80409@laposte.net>
Date:	Wed, 05 Sep 2012 21:58:06 +0200
From:	Yann Cantin <yann.cantin@...oste.net>
To:	Oliver Neukum <oneukum@...e.de>
CC:	linux-input@...r.kernel.org, linux-usb@...r.kernel.org,
	gregkh@...uxfoundation.org, dmitry.torokhov@...il.com,
	linux-kernel@...r.kernel.org, jikos@...e.cz
Subject: Re: [eBeam PATCH 2/2] input: misc: New USB eBeam input driver.

Hi,

Le 05/09/2012 09:29, Oliver Neukum a écrit :
> before we add yet another sysfs interface, we should ask whether calibration
> isn't a problem that should be solved with a common API.

Short answer : no.

##
Long answer (may be oot) :

Existing calibration tools or procedures (in kernel modules or xorg) for absolute
devices deals with hardware axis mostly matching system's ones (X screen mainly), modulo
switching XY, inversion or simple tweaks. Plus you know from the beginning the ranges
used, and all parameters are stable.

eBeam device track an active stylus in his fov, usually on a whiteboard where a
video-projector cast the computer screen. It then compute the stylus's position
and send it to the kernel in his own fixed 2D cartesian coordinate system relative
to the device.

The device is by design mobile (you stuck it anywhere on the border of the
projection plane for a session), his axis never match screen's ones, neither in range
nor orientation. Even worse, due to projection artifact, the two coordinates
systems (ebeam and screen) can even not be linearly correlated.

Manufacturer's so-called drivers seems to use second order interpolations,
i use an homography transformation (which is the right mathematical tool for
the problem, and seems quicker) to transform between coordinates systems. Anyway,
this need lot of parameters.

As ebeams are the only devices to my knowledge that work that way, i don't think
a common API can be common, unless we mean an in-kernel generic purpose calibration
API for input devices (stellar away for me), or a userland one (where should it be
in the stack ?). Sincerely, this look overkill.

In the other hand, the actual ebeam module transformation feeding events subsys
works very well and expose straight and usable data to userland (xorg evdev for now,
and any program that can eat kernel's input data).

##

I understand the sysfs interface is a problem. Eventually, in last resort, i can reduce
it to 4 files : pass the 9 matrix parameters as one big string, removing min values. But
i think this obfuscate the api for a marginal gain.

-- 
Yann Cantin
A4FEB47F
--
--
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/