linux-kernel - Re: [RFC] Add Input IOCTL for accelerometer devices

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45cc95260905190534m561d666ds1fd5d38b4a08ba5b@mail.gmail.com>
Date:	Tue, 19 May 2009 14:34:15 +0200
From:	Mohamed Ikbel Boulabiar <boulabiar@...il.com>
To:	felipe.balbi@...ia.com
Cc:	ext Kim Kyuwon <q1.kim@...sung.com>,
	ext Kim Kyuwon <chammoru@...il.com>,
	Trilok Soni <soni.trilok@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [RFC] Add Input IOCTL for accelerometer devices

Hi,

>>  > But then comes another question: what to do with
>> > magnetometers, gyroscopes, etc etc ??
>>
>> If we make a extensible sensor driver, I think we can add these new etc
>> sensors in the future. step by step.
>
> agreed here. But we have to think that this might get extended, so we
> should start thinking of an abstraction layer that could evolve for
> magnetometers, gyroscopes and other sensors

Agree with you, there should be an abstraction layer.

According to this, we should collect similar functionalities in one
module and make sub-module describing exceptions devices or ones that
needs special handling.
But in the end for the user space apps, they should "see" an
accelerometer in a standard way. All exceptions and pre-handling
should be done in the abstraction layer as described.
We can't bring as many full drivers as devices found, but one driver
serving for a group and that can load submodules when necessary.
The way HID is coded in Linux is an example for that, dealing with
many types of devices.
It isn't perfect, but its architecture can be used for other devices.

To stay with accelerometers, they are sensors, and sensors sense
physical properties.
Every device use its own methods but in the end they sense the same
thing and user wait for a similar feedback.

I post a link describing the HID standard, you can see in page 37 to
39 how they define units, and exponents for sensors.
http://www.usb.org/developers/devclass_docs/HID1_11.pdf

Also, we can't imagine all use cases and scenarios, we should bring
useful information to userspace apps and they do what they want with
these informations.
KDE developers may use sensors to automatically rotate the screen
90°/180° if the laptop is rotated. Others will use it to play games,
Some others will use light sensors to lighten the keyboard or to
change the brightness of the screen,...

What do you think ?

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