Interacting with a input kernel driver from user space

Interacting with a input kernel driver from user space

[Nuno Santos]

Hi,

I'm developing a linux kernel driver for a multitouch device. Right now 
I have already touch being injected to the linux kernel subsystem and it 
is working. The problem is that I also need to interact with the device 
to change settings an so on.

While the kernel is grabbing the device I can't grab it in user space, 
so I need to find a way to interact with the kernel driver.

My first driver test (missile laucnher example found on the internet) 
had some extra operations that I can't find on the current model i'm 
using (usbtouchscreen driver was my starting point).

It had open, close, read, write operations that I could perform from 
user space.

How can I do such things with input drivers? Is there any official way?

Thanks in advance,

With my best regards,

Nuno Santos

Re: Interacting with a input kernel driver from user space

[David Herrmann]

Hi Nuno

On Mon, Nov 14, 2011 at 1:24 PM, Nuno Santos <nsantos@edigma.com> wrote:
> Hi,
>
> I'm developing a linux kernel driver for a multitouch device. Right now I
> have already touch being injected to the linux kernel subsystem and it is
> working. The problem is that I also need to interact with the device to
> change settings an so on.
>
> While the kernel is grabbing the device I can't grab it in user space, so I
> need to find a way to interact with the kernel driver.
>
> My first driver test (missile laucnher example found on the internet) had
> some extra operations that I can't find on the current model i'm using
> (usbtouchscreen driver was my starting point).
>
> It had open, close, read, write operations that I could perform from user
> space.

There are open/close callbacks but they are only called for the first
and last application that opens/closes the device.
You should avoid character-devices with special ioctl()s if you
thought about that, though.

> How can I do such things with input drivers? Is there any official way?

The best way probably is using sysfs. Register one sysfs attribute per
value and configure your callbacks.
There are several other subsystems that provide wrappers for them. If
you could be more specific about the user-space interaction or
configuration values, then we could also be more specific (hopefully
;)).

Per driver values can be provided with module-parameters. Per device
values can be provided by sysfs attributes. For per-application/user
values you probably need special character-devices.

> Thanks in advance,
>
> With my best regards,
>
> Nuno Santos

Regards
David

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

Hi David,

Thanks for your reply.

The best way probably is using sysfs. Register one sysfs attribute per
value and configure your callbacks.
There are several other subsystems that provide wrappers for them. If
you could be more specific about the user-space interaction or
configuration values, then we could also be more specific (hopefully
;)).

sysfs? Need to dig about it. Is there any typical example I can look in kernel source? If you could point me one that would be great.

What do I need to exchange between the kernel and the user space is between a simple byte exchange and a whole structure of several bytes.

Do you know the concept of IOCTLS in windows? Basicly that's what looking after.

I need to be able to communicate to and from the device from the an application build in Qt. So, there must be something really generic that I can call from the application environment. In windows I use window API to call IOCTLS interaction.

With my best regards,

Nuno

Re: Interacting with a input kernel driver from user space

[David Herrmann]

On Mon, Nov 14, 2011 at 5:00 PM, Nuno Santos <nsantos@edigma.com> wrote:
> Hi David,
>
> Thanks for your reply.
>
> The best way probably is using sysfs. Register one sysfs attribute per
> value and configure your callbacks.
> There are several other subsystems that provide wrappers for them. If
> you could be more specific about the user-space interaction or
> configuration values, then we could also be more specific (hopefully
> ;)).
>
> sysfs? Need to dig about it. Is there any typical example I can look in
> kernel source? If you could point me one that would be great.

Almost every driver uses it. Look for "DEVICE_ATTR" in the driver
sources or drivers/input/input.c for instance.

> What do I need to exchange between the kernel and the user space is between
> a simple byte exchange and a whole structure of several bytes.
>
> Do you know the concept of IOCTLS in windows? Basicly that's what looking
> after.

No, sorry. I don't.

> I need to be able to communicate to and from the device from the an
> application build in Qt. So, there must be something really generic that I
> can call from the application environment. In windows I use window API to
> call IOCTLS interaction.

Why? I thought this thing is an input device? Why does an application
have to modify a running device? Is this modification local to the
application<->device interface or does it also affect all other
running applications that use this device?

If it is a configuration value to put the device into a different
state or similar, then you can use a sysfs attribute. The user can
change this with "echo <value> >/sys/class/input/inputX/<attribute>"

> With my best regards,
>
> Nuno

It would be really nice if you could elaborate a bit more. Tell me
what the device does and what access is needed from userspace. Then we
could try to point you to the interfaces.

Regards
David

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

On 11/14/2011 04:09 PM, David Herrmann wrote:
> On Mon, Nov 14, 2011 at 5:00 PM, Nuno Santos<nsantos@edigma.com>  wrote:
>> Hi David,
>>
>> Thanks for your reply.
>>
>> The best way probably is using sysfs. Register one sysfs attribute per
>> value and configure your callbacks.
>> There are several other subsystems that provide wrappers for them. If
>> you could be more specific about the user-space interaction or
>> configuration values, then we could also be more specific (hopefully
>> ;)).
>>
>> sysfs? Need to dig about it. Is there any typical example I can look in
>> kernel source? If you could point me one that would be great.
> Almost every driver uses it. Look for "DEVICE_ATTR" in the driver
> sources or drivers/input/input.c for instance.
Ok. I'll look for that.
>> What do I need to exchange between the kernel and the user space is between
>> a simple byte exchange and a whole structure of several bytes.
>>
>> Do you know the concept of IOCTLS in windows? Basicly that's what looking
>> after.
> No, sorry. I don't.
No problem.
>
>> I need to be able to communicate to and from the device from the an
>> application build in Qt. So, there must be something really generic that I
>> can call from the application environment. In windows I use window API to
>> call IOCTLS interaction.
> Why? I thought this thing is an input device? Why does an application
> have to modify a running device? Is this modification local to the
> application<->device interface or does it also affect all other
> running applications that use this device?
Yes, it is an multitouch overlay input device. However all the 
processing is done on the host side. The device delivers raw data into 
the system and all the tracking and touch information is processed on 
the kernel side. The control panel for this device shows the input data 
and permits some parameter change. In order to visualize that data I 
need to be able to get a complete structure from it. When I change a 
parameter it will reflect the change to the input being reported to all 
the applications that use that input device.
>
> If it is a configuration value to put the device into a different
> state or similar, then you can use a sysfs attribute. The user can
> change this with "echo<value>  >/sys/class/input/inputX/<attribute>"
For setting new simple values I see I can use this interface, but two 
questions arise. How can I send a structure with this interface? Can I 
fopen this sys file and send the whole structure thru this mechanism. 
What about receiving data from the device?

Regards,

Nuno

Re: Interacting with a input kernel driver from user space

[David Herrmann]

Hi Nuno

On Mon, Nov 14, 2011 at 5:31 PM, Nuno Santos <nsantos@edigma.com> wrote:
> On 11/14/2011 04:09 PM, David Herrmann wrote:
>>> I need to be able to communicate to and from the device from the an
>>> application build in Qt. So, there must be something really generic that
>>> I
>>> can call from the application environment. In windows I use window API to
>>> call IOCTLS interaction.
>>
>> Why? I thought this thing is an input device? Why does an application
>> have to modify a running device? Is this modification local to the
>> application<->device interface or does it also affect all other
>> running applications that use this device?
>
> Yes, it is an multitouch overlay input device. However all the processing is
> done on the host side. The device delivers raw data into the system and all
> the tracking and touch information is processed on the kernel side. The
> control panel for this device shows the input data and permits some
> parameter change. In order to visualize that data I need to be able to get a
> complete structure from it. When I change a parameter it will reflect the
> change to the input being reported to all the applications that use that
> input device.

The most straightforward approach would be applying default values I
think. If there is still a need to have variable configuration values
you should use sysfs attributes here. Maybe Dmitry knows other generic
ways in the input layer, but I would recommend sysfs attributes here.
This is never wrong ;)

>> If it is a configuration value to put the device into a different
>> state or similar, then you can use a sysfs attribute. The user can
>> change this with "echo<value>  >/sys/class/input/inputX/<attribute>"
>
> For setting new simple values I see I can use this interface, but two
> questions arise. How can I send a structure with this interface? Can I fopen
> this sys file and send the whole structure thru this mechanism. What about
> receiving data from the device?

sysfs attributes are simple files. That is, you can write to and read
from them. Please see ./Documentation/driver-model/device.txt for a
rough overview. You basically register two callbacks: read and write.
The read callback is called when userspace reads the file. You should
then pass the requested data to userspace.
The write callback is called when userspace writes the file. You
should parse the data and modify your internal structures accordingly.

But please take into account that you should never use a single
attribute for multiple values. If you need to pass a structure to the
driver then register multiple attributes, one for each member of the
structure. It is *not* bad style to have several attributes.
If there are possible race-conditions if a structure is not passed
atomically, you may violate this rule in some places.

Almost every driver today registers several attributes so it shouldn't
be hard to find examples.

> Regards,
>
> Nuno

Regards
David
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

Hi,

I have defined my first attribute in the following way:

static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
                                         struct device_attribute *attr,
                                         const char *buf, size_t count)
{

     printk(KERN_INFO "update sensibility called");

     return 0;
}

static DEVICE_ATTR(sensibility, 0664, NULL, 
usbtouchscreen_update_sensibility);

static struct attribute *usbtouchscreen_attrs[] = {
&dev_attr_sensibility.attr,
         NULL
};

static const struct attribute_group usbtouchscreen_attr_group = {
         .attrs = usbtouchscreen_attrs,
};

In the probe function I have added:

if (sysfs_create_group(&intf->dev.kobj, &usbtouchscreen_attr_group))
         goto out_unregister_input;


Then I tried to write on the attribute in the following way:

nsantos@NS-PC:~/workspaces/linux-kernel-driver$ echo 45 > 
/sys/class/input/input7/sensibility
bash: /sys/class/input/input7/sensibility: No such file or directory

After digging a bit under /sys/class/input/input7 i found that the sub 
directory device add sensibilty listed so I tried the following:

nsantos@NS-PC:~/workspaces/workspace-mtt/linux-kernel-driver$ sudo echo 
45 > /sys/class/input/input7/device/sensibility
bash: /sys/class/input/input7/device/sensibility: Permission denied

With no success again...

Am I doing something terribly wrong?

Thanks in advance,

Regards,

Nuno

Re: Interacting with a input kernel driver from user space

[Dmitry Torokhov]

On Monday, November 14, 2011 10:24:17 AM Nuno Santos wrote:
> Hi,
> 
> I have defined my first attribute in the following way:
> 
> static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
>                                          struct device_attribute *attr,
>                                          const char *buf, size_t count)
> {
> 
>      printk(KERN_INFO "update sensibility called");
> 

Updating sensibility is always a good thing but I gather you mean 
sensitivity here...

BTW this should probably be a per-user setting and belong to the X driver, 
not kernel driver. I.e. kernel streams all data and userspace (X) decides 
what data do discard according to current user preferences.

>      return 0;
> }
> 
> static DEVICE_ATTR(sensibility, 0664, NULL,
> usbtouchscreen_update_sensibility);
> 
> static struct attribute *usbtouchscreen_attrs[] = {
> &dev_attr_sensibility.attr,
>          NULL
> };
> 
> static const struct attribute_group usbtouchscreen_attr_group = {
>          .attrs = usbtouchscreen_attrs,
> };
> 
> In the probe function I have added:
> 
> if (sysfs_create_group(&intf->dev.kobj, &usbtouchscreen_attr_group))
>          goto out_unregister_input;
> 
> 
> Then I tried to write on the attribute in the following way:
> 
> nsantos@NS-PC:~/workspaces/linux-kernel-driver$ echo 45 >
> /sys/class/input/input7/sensibility
> bash: /sys/class/input/input7/sensibility: No such file or directory
> 
> After digging a bit under /sys/class/input/input7 i found that the sub
> directory device add sensibilty listed so I tried the following:
> 
> nsantos@NS-PC:~/workspaces/workspace-mtt/linux-kernel-driver$ sudo echo
> 45 > /sys/class/input/input7/device/sensibility
> bash: /sys/class/input/input7/device/sensibility: Permission denied
> 
> With no success again...
> 
> Am I doing something terribly wrong?

You aren't doing this as root and don't have permission to access the 
attribute.

-- 
Dmitry

Re: Interacting with a input kernel driver from user space

[Oliver Neukum]

Am Montag, 14. November 2011, 19:57:41 schrieb Dmitry Torokhov:
> On Monday, November 14, 2011 10:24:17 AM Nuno Santos wrote:
> > Hi,
> > 
> > I have defined my first attribute in the following way:
> > 
> > static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
> >                                          struct device_attribute *attr,
> >                                          const char *buf, size_t count)
> > {
> > 
> >      printk(KERN_INFO "update sensibility called");
> > 
> 
> Updating sensibility is always a good thing but I gather you mean 
> sensitivity here...
> 
> BTW this should probably be a per-user setting and belong to the X driver, 
> not kernel driver. I.e. kernel streams all data and userspace (X) decides 
> what data do discard according to current user preferences.

Hi,

before we define yet another interface specific to a driver, could we discuss
whether this interface could be applicable to a wider range of devices?

	Regards
		Oliver

Re: Interacting with a input kernel driver from user space

[Dmitry Torokhov]

On Monday, November 14, 2011 03:17:17 PM Oliver Neukum wrote:
> Am Montag, 14. November 2011, 19:57:41 schrieb Dmitry Torokhov:
> > On Monday, November 14, 2011 10:24:17 AM Nuno Santos wrote:
> > > Hi,
> > > 
> > > I have defined my first attribute in the following way:
> > > 
> > > static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
> > > 
> > >                                          struct device_attribute
> > >                                          *attr, const char *buf,
> > >                                          size_t count)
> > > 
> > > {
> > > 
> > >      printk(KERN_INFO "update sensibility called");
> > 
> > Updating sensibility is always a good thing but I gather you mean
> > sensitivity here...
> > 
> > BTW this should probably be a per-user setting and belong to the X
> > driver, not kernel driver. I.e. kernel streams all data and userspace
> > (X) decides what data do discard according to current user
> > preferences.
> 
> Hi,
> 
> before we define yet another interface specific to a driver, could we
> discuss whether this interface could be applicable to a wider range of
> devices?

... and whether it should be a kernel userspace at all...

-- 
Dmitry

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

On 11/14/2011 11:34 PM, Dmitry Torokhov wrote:
> On Monday, November 14, 2011 03:17:17 PM Oliver Neukum wrote:
>> Am Montag, 14. November 2011, 19:57:41 schrieb Dmitry Torokhov:
>>> On Monday, November 14, 2011 10:24:17 AM Nuno Santos wrote:
>>>> Hi,
>>>>
>>>> I have defined my first attribute in the following way:
>>>>
>>>> static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
>>>>
>>>>                                           struct device_attribute
>>>>                                           *attr, const char *buf,
>>>>                                           size_t count)
>>>>
>>>> {
>>>>
>>>>       printk(KERN_INFO "update sensibility called");
>>> Updating sensibility is always a good thing but I gather you mean
>>> sensitivity here...
>>>
>>> BTW this should probably be a per-user setting and belong to the X
>>> driver, not kernel driver. I.e. kernel streams all data and userspace
>>> (X) decides what data do discard according to current user
>>> preferences.
>> Hi,
>>
>> before we define yet another interface specific to a driver, could we
>> discuss whether this interface could be applicable to a wider range of
>> devices?
> ... and whether it should be a kernel userspace at all...
>

Well, I can't really tell what it should because i'm little aware of all 
the possibilities provided by the linux OS.

I'm a not a specialist in any OS. However, i'm a daily user of all the 
main operating systems Mac, Windows and Linux.

As a kernel developer I have only developed the device driver for 
Windows 7 and now i'm writing it to Linux.


Thanks,

Nuno

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

On 11/14/2011 11:17 PM, Oliver Neukum wrote:
> Am Montag, 14. November 2011, 19:57:41 schrieb Dmitry Torokhov:
>> On Monday, November 14, 2011 10:24:17 AM Nuno Santos wrote:
>>> Hi,
>>>
>>> I have defined my first attribute in the following way:
>>>
>>> static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
>>>                                           struct device_attribute *attr,
>>>                                           const char *buf, size_t count)
>>> {
>>>
>>>       printk(KERN_INFO "update sensibility called");
>>>
>> Updating sensibility is always a good thing but I gather you mean
>> sensitivity here...
>>
>> BTW this should probably be a per-user setting and belong to the X driver,
>> not kernel driver. I.e. kernel streams all data and userspace (X) decides
>> what data do discard according to current user preferences.
> Hi,
>
> before we define yet another interface specific to a driver, could we discuss
> whether this interface could be applicable to a wider range of devices
Of course. If I can contribute with my little experience for something I 
would have all the pleasure.

Do you guyz want me to describe my case in detail?

With my best regards,

Nuno

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

On 11/14/2011 06:57 PM, Dmitry Torokhov wrote:
> On Monday, November 14, 2011 10:24:17 AM Nuno Santos wrote:
>> Hi,
>>
>> I have defined my first attribute in the following way:
>>
>> static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
>>                                           struct device_attribute *attr,
>>                                           const char *buf, size_t count)
>> {
>>
>>       printk(KERN_INFO "update sensibility called");
>>
> Updating sensibility is always a good thing but I gather you mean
> sensitivity here...

hahaahha thanks for the correction!!!! I need to do it in several places 
now! :)
>
> BTW this should probably be a per-user setting and belong to the X driver,
> not kernel driver. I.e. kernel streams all data and userspace (X) decides
> what data do discard according to current user preferences.
didn't knew about this capability. but how do you change the settings 
thru X? where can I find the API for that?
>
>>       return 0;
>> }
>>
>> static DEVICE_ATTR(sensibility, 0664, NULL,
>> usbtouchscreen_update_sensibility);
>>
>> static struct attribute *usbtouchscreen_attrs[] = {
>> &dev_attr_sensibility.attr,
>>           NULL
>> };
>>
>> static const struct attribute_group usbtouchscreen_attr_group = {
>>           .attrs = usbtouchscreen_attrs,
>> };
>>
>> In the probe function I have added:
>>
>> if (sysfs_create_group(&intf->dev.kobj,&usbtouchscreen_attr_group))
>>           goto out_unregister_input;
>>
>>
>> Then I tried to write on the attribute in the following way:
>>
>> nsantos@NS-PC:~/workspaces/linux-kernel-driver$ echo 45>
>> /sys/class/input/input7/sensibility
>> bash: /sys/class/input/input7/sensibility: No such file or directory
>>
>> After digging a bit under /sys/class/input/input7 i found that the sub
>> directory device add sensibilty listed so I tried the following:
>>
>> nsantos@NS-PC:~/workspaces/workspace-mtt/linux-kernel-driver$ sudo echo
>> 45>  /sys/class/input/input7/device/sensibility
>> bash: /sys/class/input/input7/device/sensibility: Permission denied
>>
>> With no success again...
>>
>> Am I doing something terribly wrong?
> You aren't doing this as root and don't have permission to access the
> attribute.
sudo doesn't work in this case? Because I was suddoing. if I change the 
attribute to 777 will it be available to everyone? is this a good way of 
doing it?


Sorry for all this questions. Is my first linux driver ever!

Thanks,

With my best regards,

Nuno

Re: Interacting with a input kernel driver from user space

[Dmitry Torokhov]

On Tue, Nov 15, 2011 at 09:35:14AM +0000, Nuno Santos wrote:
> On 11/14/2011 06:57 PM, Dmitry Torokhov wrote:
> >On Monday, November 14, 2011 10:24:17 AM Nuno Santos wrote:
> >>Hi,
> >>
> >>I have defined my first attribute in the following way:
> >>
> >>static ssize_t usbtouchscreen_update_sensibility(struct device *dev,
> >>                                          struct device_attribute *attr,
> >>                                          const char *buf, size_t count)
> >>{
> >>
> >>      printk(KERN_INFO "update sensibility called");
> >>
> >Updating sensibility is always a good thing but I gather you mean
> >sensitivity here...
> 
> hahaahha thanks for the correction!!!! I need to do it in several
> places now! :)
> >
> >BTW this should probably be a per-user setting and belong to the X driver,
> >not kernel driver. I.e. kernel streams all data and userspace (X) decides
> >what data do discard according to current user preferences.
> didn't knew about this capability. but how do you change the
> settings thru X? where can I find the API for that?

This API is private to particular X driver. For example Synaptics X
driver (that handles all touchpads that we support in Linux, be it
actualy Synaptics, ALPS, Elantech, Sentelic, Broadcom, etc) allows user
select touch sensitivity. If device support pressure reading
(ABS_PRESSURE) then X driver will simply ignore all event packets where
pressure is less than the threshold. The kernel portion still streams
all events; the X portion is simply choses to ignore some of them,
according to user preference.

> >
> >>      return 0;

Actually this shoudl be

	return count;

> >>}
> >>
> >>static DEVICE_ATTR(sensibility, 0664, NULL,
> >>usbtouchscreen_update_sensibility);
> >>
> >>static struct attribute *usbtouchscreen_attrs[] = {
> >>&dev_attr_sensibility.attr,
> >>          NULL
> >>};
> >>
> >>static const struct attribute_group usbtouchscreen_attr_group = {
> >>          .attrs = usbtouchscreen_attrs,
> >>};
> >>
> >>In the probe function I have added:
> >>
> >>if (sysfs_create_group(&intf->dev.kobj,&usbtouchscreen_attr_group))
> >>          goto out_unregister_input;
> >>
> >>
> >>Then I tried to write on the attribute in the following way:
> >>
> >>nsantos@NS-PC:~/workspaces/linux-kernel-driver$ echo 45>
> >>/sys/class/input/input7/sensibility
> >>bash: /sys/class/input/input7/sensibility: No such file or directory
> >>
> >>After digging a bit under /sys/class/input/input7 i found that the sub
> >>directory device add sensibilty listed so I tried the following:
> >>
> >>nsantos@NS-PC:~/workspaces/workspace-mtt/linux-kernel-driver$ sudo echo
> >>45>  /sys/class/input/input7/device/sensibility
> >>bash: /sys/class/input/input7/device/sensibility: Permission denied
> >>
> >>With no success again...
> >>
> >>Am I doing something terribly wrong?
> >You aren't doing this as root and don't have permission to access the
> >attribute.
> sudo doesn't work in this case? Because I was suddoing.

Should have worked, something else must be wrong then.

> if I change
> the attribute to 777 will it be available to everyone? is this a
> good way of doing it?

Generally we restrict access to sysfs attributes to root since they
control behavior for all users, not only one why is changin sysfs
attribute.

BTW, please use "reply-all" on linux kernel mailing lists - it is most
preferred method. This way you ensure faster responses from people who
already participating in the thread as I scan my inbox is much more
often than folder where I save linux-input mails.

-- 
Dmitry

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

Generally we restrict access to sysfs attributes to root since they
control behavior for all users, not only one why is changin sysfs
attribute.


Hummm... that leads me to a question. How can I make use of such attributes inside an application without having root access? Imagine that I open the control panel of the device in a user account, the contol panel itself will not have access to the attributes and it will not work. How do I overcome this problem?

Imagine that my device is a soundcard and it has a beautifull control panel to control non general parameters. What would be the interface used by the control panel to access the kernel driver and modify the soundcard parameters?


BTW, please use "reply-all" on linux kernel mailing lists - it is most
preferred method. This way you ensure faster responses from people who
already participating in the thread as I scan my inbox is much more
often than folder where I save linux-input mails.

:) I noticed that all of you were replying that way but couldn't understand why. Thanks.

Regards,

Nuno

Re: Interacting with a input kernel driver from user space

[Dmitry Torokhov]

On Tue, Nov 15, 2011 at 06:41:53PM +0000, Nuno Santos wrote:
> Generally we restrict access to sysfs attributes to root since they
> control behavior for all users, not only one why is changin sysfs
> attribute.
> 
> 
> Hummm... that leads me to a question. How can I make use of such
> attributes inside an application without having root access? Imagine
> that I open the control panel of the device in a user account, the
> contol panel itself will not have access to the attributes and it will
> not work. How do I overcome this problem?

Applications could register with ConsoleKit to elevate their privileges
if needed if they are running in a context of user logged onto local
console as opposed to someone logging in removely.

> 
> Imagine that my device is a soundcard and it has a beautifull control
> panel to control non general parameters. What would be the interface
> used by the control panel to access the kernel driver and modify the
> soundcard parameters?
> 

Beautful control panel does not normally even talk to sound card
directly but rather plugs into desktop environment infrastructure which
plugs into sound server inforastructure which in turn knows how to talk
to the hardware. Take a look at the sound mixer applet. As you can see
it actually exports only standard parameters and is pretty bland in this
regard (and this is a good thing - it supposed to work uniformly on all
hardware). The best way if advanved parameters have sensible defaults and
need not to be touched at all.

I guess here you see the difference between Linux and Windows views
because we actually do not want vendor-specific applets/tray
icons/utilities/etc but rather unified interface working for all
hardware in a given class.

Thanks.

-- 
Dmitry

Re: Interacting with a input kernel driver from user space

[Dmitry Torokhov]

On Mon, Nov 14, 2011 at 04:31:57PM +0000, Nuno Santos wrote:
> On 11/14/2011 04:09 PM, David Herrmann wrote:
> >On Mon, Nov 14, 2011 at 5:00 PM, Nuno Santos<nsantos@edigma.com>  wrote:
> >>Hi David,
> >>
> >>Thanks for your reply.
> >>
> >>The best way probably is using sysfs. Register one sysfs attribute per
> >>value and configure your callbacks.
> >>There are several other subsystems that provide wrappers for them. If
> >>you could be more specific about the user-space interaction or
> >>configuration values, then we could also be more specific (hopefully
> >>;)).
> >>
> >>sysfs? Need to dig about it. Is there any typical example I can look in
> >>kernel source? If you could point me one that would be great.
> >Almost every driver uses it. Look for "DEVICE_ATTR" in the driver
> >sources or drivers/input/input.c for instance.
> Ok. I'll look for that.
> >>What do I need to exchange between the kernel and the user space is between
> >>a simple byte exchange and a whole structure of several bytes.
> >>
> >>Do you know the concept of IOCTLS in windows? Basicly that's what looking
> >>after.
> >No, sorry. I don't.
> No problem.
> >
> >>I need to be able to communicate to and from the device from the an
> >>application build in Qt. So, there must be something really generic that I
> >>can call from the application environment. In windows I use window API to
> >>call IOCTLS interaction.
> >Why? I thought this thing is an input device? Why does an application
> >have to modify a running device? Is this modification local to the
> >application<->device interface or does it also affect all other
> >running applications that use this device?
> Yes, it is an multitouch overlay input device. However all the
> processing is done on the host side. The device delivers raw data
> into the system and all the tracking and touch information is
> processed on the kernel side. The control panel for this device
> shows the input data and permits some parameter change. In order to
> visualize that data I need to be able to get a complete structure
> from it. When I change a parameter it will reflect the change to the
> input being reported to all the applications that use that input
> device.
> >
> >If it is a configuration value to put the device into a different
> >state or similar, then you can use a sysfs attribute. The user can
> >change this with "echo<value>  >/sys/class/input/inputX/<attribute>"
> For setting new simple values I see I can use this interface, but
> two questions arise. How can I send a structure with this interface?

Yes, using binary attributes.

> Can I fopen this sys file and send the whole structure thru this
> mechanism. What about receiving data from the device?

Depend on the kind of data you need to get. Is the device state as
delivered through input device is not enough? Then maybe you don't want
to use input interface but rather use something like hiddev or hidraw
for direct access to the device, do the needed processing in userspace
and then use uinput to route the events back to kernel for distribution.

However so far we managed to do contact tracking in kernel...

What I do not want to have is custom input driver ioctls; I want clients
to work off declared input capabilities aas much as possible.

Thanks.

-- 
Dmitry

Re: Interacting with a input kernel driver from user space

[Henrik Rydberg]

> > >>I need to be able to communicate to and from the device from the an
> > >>application build in Qt. So, there must be something really generic that I
> > >>can call from the application environment. In windows I use window API to
> > >>call IOCTLS interaction.
> > >Why? I thought this thing is an input device? Why does an application
> > >have to modify a running device? Is this modification local to the
> > >application<->device interface or does it also affect all other
> > >running applications that use this device?
> > Yes, it is an multitouch overlay input device. However all the
> > processing is done on the host side. The device delivers raw data
> > into the system and all the tracking and touch information is
> > processed on the kernel side. The control panel for this device
> > shows the input data and permits some parameter change. In order to
> > visualize that data I need to be able to get a complete structure
> > from it. When I change a parameter it will reflect the change to the
> > input being reported to all the applications that use that input
> > device.
> > >
> > >If it is a configuration value to put the device into a different
> > >state or similar, then you can use a sysfs attribute. The user can
> > >change this with "echo<value>  >/sys/class/input/inputX/<attribute>"
> > For setting new simple values I see I can use this interface, but
> > two questions arise. How can I send a structure with this interface?
> 
> Yes, using binary attributes.
> 
> > Can I fopen this sys file and send the whole structure thru this
> > mechanism. What about receiving data from the device?
> 
> Depend on the kind of data you need to get. Is the device state as
> delivered through input device is not enough? Then maybe you don't want
> to use input interface but rather use something like hiddev or hidraw
> for direct access to the device, do the needed processing in userspace
> and then use uinput to route the events back to kernel for distribution.
> 
> However so far we managed to do contact tracking in kernel...
> 
> What I do not want to have is custom input driver ioctls; I want clients
> to work off declared input capabilities aas much as possible.

Right. Unless we are talking about haptic feedback or leds,
information really flows one way, so there should be no reason to send
anything back to the kernel. For detected but anonymous touches, we
have MT protocol A in the input subsystem. If your raw data does not
even contain detected touches, I would try hidraw, as Dmitry
suggested.

Thanks,
Henrik

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

But my device isn't an HID device. My device is a vendor specific device:

bNumEndpoints           2
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass    255 Vendor Specific Subclass
       bInterfaceProtocol    255 Vendor Specific Protocol
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x86  EP 6 IN
         bmAttributes            2
           Transfer Type            Bulk
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0200  1x 512 bytes
         bInterval               0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x02  EP 2 OUT
         bmAttributes            2
           Transfer Type            Bulk
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0200  1x 512 bytes
         bInterval               0


I need bulk transfers for data in and out.

--

Right. Unless we are talking about haptic feedback or leds, information 
really flows one way, so there should be no reason to send anything back 
to the kernel. For detected but anonymous touches, we have MT protocol A 
in the input subsystem. If your raw data does not even contain detected 
touches, I would try hidraw, as Dmitry suggested. Thanks, Henrik

Re: Interacting with a input kernel driver from user space

[Chase Douglas]

On 11/15/2011 02:32 AM, Henrik Rydberg wrote:
>>>>> I need to be able to communicate to and from the device from the an
>>>>> application build in Qt. So, there must be something really generic that I
>>>>> can call from the application environment. In windows I use window API to
>>>>> call IOCTLS interaction.
>>>> Why? I thought this thing is an input device? Why does an application
>>>> have to modify a running device? Is this modification local to the
>>>> application<->device interface or does it also affect all other
>>>> running applications that use this device?
>>> Yes, it is an multitouch overlay input device. However all the
>>> processing is done on the host side. The device delivers raw data
>>> into the system and all the tracking and touch information is
>>> processed on the kernel side. The control panel for this device
>>> shows the input data and permits some parameter change. In order to
>>> visualize that data I need to be able to get a complete structure
>>> from it. When I change a parameter it will reflect the change to the
>>> input being reported to all the applications that use that input
>>> device.
>>>>
>>>> If it is a configuration value to put the device into a different
>>>> state or similar, then you can use a sysfs attribute. The user can
>>>> change this with "echo<value>  >/sys/class/input/inputX/<attribute>"
>>> For setting new simple values I see I can use this interface, but
>>> two questions arise. How can I send a structure with this interface?
>>
>> Yes, using binary attributes.
>>
>>> Can I fopen this sys file and send the whole structure thru this
>>> mechanism. What about receiving data from the device?
>>
>> Depend on the kind of data you need to get. Is the device state as
>> delivered through input device is not enough? Then maybe you don't want
>> to use input interface but rather use something like hiddev or hidraw
>> for direct access to the device, do the needed processing in userspace
>> and then use uinput to route the events back to kernel for distribution.
>>
>> However so far we managed to do contact tracking in kernel...
>>
>> What I do not want to have is custom input driver ioctls; I want clients
>> to work off declared input capabilities aas much as possible.
> 
> Right. Unless we are talking about haptic feedback or leds,
> information really flows one way, so there should be no reason to send
> anything back to the kernel. For detected but anonymous touches, we
> have MT protocol A in the input subsystem. If your raw data does not
> even contain detected touches, I would try hidraw, as Dmitry
> suggested.

We may want to look into creating a mechanism for taking raw bitmap data
and assigning touch points. ALPS trackpads and apparently Nuno's device
provide raw data and need touch point recognition processing.

Perhaps we could take the code in the ALPS driver and generalize it?

-- Chase

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

We may want to look into creating a mechanism for taking raw bitmap data
and assigning touch points. ALPS trackpads and apparently Nuno's device
provide raw data and need touch point recognition processing.

Perhaps we could take the code in the ALPS driver and generalize it?


While we belive that further improvements to our device will lead to 
have the processing be made inside the device, if we want to see the 
sensing matrix as we do now we definitly will need that feature

Regards,

Nuno

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

By the way...

Since everytime I plug the device a different input dir is created in 
/sys/class/input , how should I determine if my device is connected in 
the most straight forward way?

Thanks,

With my best regards,

Nuno

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

     Why? I thought this thing is an input device? Why does an 
application have to modify a running device? Is this modification local 
to the application<->device interface or does it also affect all other 
running applications that use this device? If it is a configuration 
value to put the device into a different state or similar, then you can 
use a sysfs attribute. The user can change this with "echo <value> 
 >/sys/class/input/inputX/<attribute>"

I'm already with working examples of ATTRIB in my driver project. The 
thing is that I have random kernel panics when I try to read from the 
attribute. This is my attribute code:

static ssize_t usbtouchscreen_get_state(struct device *dev, struct 
device_attribute *attr, char *buf)
{
     int count=0;
     struct usbtouch_usb *usbtouch = dev_get_drvdata(dev);
     struct dpx_priv *priv = usbtouch->priv;

     printk(KERN_INFO "state length: %d",sizeof(DPX_DEVICE_STATE)); // 
size = 43196 bytes

     memcpy(buf,(void*)&priv->context->State,sizeof(DPX_DEVICE_STATE));

     return sizeof(DPX_DEVICE_STATE);
}

static DEVICE_ATTR(state, 0777, usbtouchscreen_get_state, NULL);

Should I make anykind of protection while doing this operation? I have 
read in some answer from you guys, that I should create an attribute for 
every field of the structure I want to bring to userspace, but that will 
make me have tenths of attributes. The problem for me are not the number 
of attributes, but the changes I will need to have in my control panel 
to support that architecture. One attribute with the content of State 
variable would be perfect.

Any ideas?

Thanks,

Nuno

Re: Interacting with a input kernel driver from user space

[Dmitry Torokhov]

Hi Nuno,

On Wed, Nov 16, 2011 at 05:28:13PM +0000, Nuno Santos wrote:
>     Why? I thought this thing is an input device? Why does an
> application have to modify a running device? Is this modification
> local to the application<->device interface or does it also affect
> all other running applications that use this device? If it is a
> configuration value to put the device into a different state or
> similar, then you can use a sysfs attribute. The user can change
> this with "echo <value> >/sys/class/input/inputX/<attribute>"

Any chance you could use some sane quoting style? It is almost
impossible to dechipher where someone else's mail stops and your reply
starts.

> 
> I'm already with working examples of ATTRIB in my driver project.
> The thing is that I have random kernel panics when I try to read
> from the attribute. This is my attribute code:
> 
> static ssize_t usbtouchscreen_get_state(struct device *dev, struct
> device_attribute *attr, char *buf)
> {
>     int count=0;
>     struct usbtouch_usb *usbtouch = dev_get_drvdata(dev);
>     struct dpx_priv *priv = usbtouch->priv;
> 
>     printk(KERN_INFO "state length: %d",sizeof(DPX_DEVICE_STATE));
> // size = 43196 bytes

So it is probably 39K more than sysfs attribute can handle.

> 
>     memcpy(buf,(void*)&priv->context->State,sizeof(DPX_DEVICE_STATE));

and you are smashing kernel stack here.

-- 
Dmitry

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

On 11/16/2011 07:27 PM, Dmitry Torokhov wrote:
> Hi Nuno,
>
> On Wed, Nov 16, 2011 at 05:28:13PM +0000, Nuno Santos wrote:
>>      Why? I thought this thing is an input device? Why does an
>> application have to modify a running device? Is this modification
>> local to the application<->device interface or does it also affect
>> all other running applications that use this device? If it is a
>> configuration value to put the device into a different state or
>> similar, then you can use a sysfs attribute. The user can change
>> this with "echo<value>  >/sys/class/input/inputX/<attribute>"
> Any chance you could use some sane quoting style? It is almost
> impossible to dechipher where someone else's mail stops and your reply
> starts.
Yes, sorry.
>
>> I'm already with working examples of ATTRIB in my driver project.
>> The thing is that I have random kernel panics when I try to read
>> from the attribute. This is my attribute code:
>>
>> static ssize_t usbtouchscreen_get_state(struct device *dev, struct
>> device_attribute *attr, char *buf)
>> {
>>      int count=0;
>>      struct usbtouch_usb *usbtouch = dev_get_drvdata(dev);
>>      struct dpx_priv *priv = usbtouch->priv;
>>
>>      printk(KERN_INFO "state length: %d",sizeof(DPX_DEVICE_STATE));
>> // size = 43196 bytes
> So it is probably 39K more than sysfs attribute can handle.
Ok, I found on documentation that buffer size is maximum PAGE_SIZE
>
>>      memcpy(buf,(void*)&priv->context->State,sizeof(DPX_DEVICE_STATE));
> and you are smashing kernel stack here.
Now that i'm copying the proper amount of data I have another problem. 
I'm actually reading this attribute constantly when I open my control 
panel, however it seems that I can only have reading results from second 
to second. Is there anything that limits the amount of times I can push 
attribute data per second? I would definitily need at least 40 readings 
per second in order to have my data visualized in control panel.

Thanks,

Nuno

Re: Interacting with a input kernel driver from user space

[Nuno Santos]

 > Now that i'm copying the proper amount of data I have another
 > problem. I'm actually reading this attribute constantly when I open
 > my control panel, however it seems that I can only have reading
 > results from second to second. Is there anything that limits the
 > amount of times I can push attribute data per second? I would
 > definitily need at least 40 readings per second in order to have my
 > data visualized in control panel.

I had overcome this problem using binary attributes. It's blazing fast now.

First I tried with a 4096 length attribute. But when I tried to transfer 
the whole state variable, the one that size is 40k length, I got kernel 
error at the middle of the transfer. My guess in that case is that the 
operation is not atomic and the variable was written between bin 
attribute read calls. Does this make sense?

Having such an attribute would really spare me a lot of time doing the 
control panel interaction and it would make me windows version and linux 
version very similiar, therefore I would use the very mechanisms.

With this said, i'm not discarding all the thing that you guys I have 
been telling me in the last emails and with the time I can make my head 
clear for structural changes in order to make this become better with 
the time in both OS's.

Thanks,

Nuno