Re: Can I limit the scope of an input device to specific processes ?

["Dr. Zimmermann" <R.Zimmermann@UKE.Uni-Hamburg.de>]

[-- Attachment #1: Type: text/plain, Size: 8538 bytes --]

Am 29.01.2014 13:31, schrieb Fabien André:
> An alternative to X config file is the xinput command line tool
>
> $> xinput list
> to get the name and id of your device
> $>xinput float NAME_OR_ID
> to "detach" the device from the virtual core keyboard
> (the name will be stable while id can change after unplug or restart, thus
> name is a better candidate for scripting)

Hi Fabien,

that looks promising: I was able to separate our response-box-keyboards 
from the core keyboard so that pressed (response-)keys are no longer 
transmitted by default anymore.

Can You shortly point me to the next steps necessary?
-> Create e new core pointer/keyboard pair and connect the 
reponse-box-keyboard to it?

Or is there a better forum to ask about X (input) stuff?

Thanx, Roger
>
>
>
> On Wed, Jan 29, 2014 at 10:44 AM, Dr. Zimmermann <
> R.Zimmermann@uke.uni-hamburg.de> wrote:
>
>> Am 28.01.2014 13:49, schrieb David Herrmann:
>>
>>> Hi
>>>
>>>   Hi David,
>>
>>   On Tue, Jan 28, 2014 at 1:27 PM, Dr. Zimmermann
>>> <R.Zimmermann@uke.uni-hamburg.de> wrote:
>>>
>>>> Am 28.01.2014 12:15, schrieb David Herrmann:
>>>>
>>>>   Hi
>>>>>
>>>>> On Tue, Jan 28, 2014 at 11:20 AM, Dr. Zimmermann
>>>>> <R.Zimmermann@uke.uni-hamburg.de> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> we've got a special type of keyboard which should only be available in
>>>>>> one
>>>>>> specific process and not publicly, as usually keyboards are.
>>>>>>
>>>>>> Is it possible to limit the scope of a specific keyboard?
>>>>>>
>>>>>> Or is there a more suited forum where to ask?
>>>>>>
>>>>>
>>>>
>>>> Hi David,
>>>>
>>>>
>>>>
>>>>> There is no such interface in the kernel. However, with careful
>>>>> access-management, you can get what you want by just allowing your
>>>>> single process access to the device. But I guess you are working with
>>>>> an X11 system, so a description of what you actually want to achieve
>>>>> would help a lot.
>>>>>
>>>>
>>>>
>>>> Thnx for Your quick reply.
>>>>
>>>> (Yes, we are using X. No, the problem is not specific to X: It'll also
>>>> occur
>>>> when You switch between system consoles.)
>>>>
>>>
>>> Just don't use the system-console for that. It's not intended for that
>>> purpose and no-one will enhance it to do device-separation (why would
>>> you.. it's mainly meant as system-administrator fallback). But see
>>> below..
>>>
>>
>> We've never intended to use it for our purposes, still the effect that
>> we've got is the same than under X.
>>
>>
>>>   For research purposes we are measuring human brain activity under the
>>>> influence of external stimuli (visual/auditory/somatosensory). The
>>>> subject
>>>> has to reply to tasks using 'button boxes' which are implemented as
>>>> keyboards. Usually, type and time of the buttonpress are of importance
>>>> (and
>>>> will probably change further procedere). Keyboard responses usually go to
>>>> that window (or system console) which has the current focus or is active
>>>> and
>>>> *this* is something, we do not want.
>>>>
>>>> Sometimes we show visual stimuli on one screen(#1) and operate the system
>>>> from another screen(#2). Sometimes we even have no visual stimuli at all,
>>>> but like to read subject responses and control the stimuli from within a
>>>> control window. In all cases it would be helpful if the response-boxes
>>>> would
>>>> not automatically send their output to the active window resp.
>>>> application.
>>>>
>>>> Helpful would be, if the output of the response-box-keyboards
>>>> * could be restricted to a specific process
>>>> * is not sent automatically, but only to a program which 'opened' the
>>>> device
>>>> * is not sent automatically, but has to be read from a device.
>>>> (Could this be done preserving the exact timepoint of each buttonpress?)
>>>>
>>>
>>> First of all, nothing is "sent automatically". Processes have to read
>>> the events from the kernel, so point #3 doesn't make much sense to me.
>>>
>>
>> Think of me as quite unaware in these matters. I'm seeing this 'signal'
>> (keyboard events) distributed by default to every application which gets
>> active/the focus.
>>
>>   But regarding your issue: You should simply configure you xserver to
>>> not use the devices in question. Add an X11 config to
>>> /etc/X11/xorg.conf.d/50-ignore-custom-devices.conf which contains
>>> something like:
>>>
>>> Section "InputClass"
>>>       Identifier "Custom Input Blacklist"
>>>       MatchProduct "<Product-Name-of-Your-Device>"
>>>       MatchDevicePath "/dev/input/event*"
>>>       Option "Ignore" "on"
>>> EndSection
>>>
>>> You can read the product-name of your device via: `cat
>>> /sys/class/input/input<num>/name`
>>> where "input<num>" is your device in question.
>>>
>>> This will cause the Xserver to stop using your input devices and no
>>> window will get any events from them. Now you can program your custom
>>> applications to open the correct devices manually and reading events
>>> from them. However, this requires modifications to these applications.
>>> But if you just want your xserver to route specific events to specific
>>> processes, your applications must be XInput2-aware/capable.
>>>
>>> Instructing the kernel to route specific events to specific processes
>>> is the wrong approach here (except regarding the linux-console, which
>>> is special but *really* shouldn't be used for such stuff). The kernel
>>> does not care for policy but only provides hardware-abstraction. It's
>>> up to your applications to use the correct X11 APIs to only read
>>> events from specific XInput2-devices. So the correct people to ask
>>> about this are actually the developers of your applications and the
>>> X11 people. The kernel, by default, restricts input-device access to
>>> root, so basically *no* user gets input access. The X-Server now
>>> applies some default policies on these devices to route events to X11
>>> applications. By default, hot-plugging is enabled in new X-Servers and
>>> all devices are markes as Master devices. This means, their events are
>>> broad-casted to all X11 windows. If you don't want that, you can mark
>>> devices as "Floating", which means, the device will not broadcast
>>> events, but use the XInput API to report input events. Only
>>> applications which use XInput can now request events from the device.
>>>
>>> You can mark devices as floating via:
>>> Section "InputClass"
>>>       Identifier "Custom Input Blacklist"
>>>       MatchProduct "<Product-Name-of-Your-Device>"
>>>       MatchDevicePath "/dev/input/event*"
>>>       Option "Floating" "on"
>>> EndSection
>>>
>>> Also see "man xorg.conf" and search for "Floating".
>>>
>>
>> Thanks for this explanation. It helped a lot and I now see, which 'path'
>> to go on...
>>
>>>
>>> I hope that helps! I it's still unclear, let me know.
>>> As a side-note, please always put the mailing-lists on CC. I'm not
>>> doing that myself now, as I don't know whether you excluded them on
>>> purpose. But if you start a discussion on the mailing-list, you should
>>> keep it there so other people can comment, too. Most mail-clients
>>> provide the "reply to all" feature to do that automatically.
>>>
>> My mailer didn't do it correctly. But short time after the mail to You,
>> the same mail was sent to the list manually...
>>
>>>
>>> Thanks
>>> David
>>>
>>
>> Thanks again & Regards,
>> Roger
>>
>>   .
>>>
>>>
>> --
>>
>> Besuchen Sie uns auf: www.uke.de
>> _____________________________________________________________________
>>
>> Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen
>> Rechts; Gerichtsstand: Hamburg
>> Vorstandsmitglieder: Prof. Dr. Christian Gerloff (Vertreter des
>> Vorsitzenden), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik
>> _____________________________________________________________________
>>
>> SAVE PAPER - THINK BEFORE PRINTING
>>
>

--

Besuchen Sie uns auf: www.uke.de
_____________________________________________________________________

Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg
Vorstandsmitglieder: Prof. Dr. Christian Gerloff (Vertreter des Vorsitzenden), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik
_____________________________________________________________________

SAVE PAPER - THINK BEFORE PRINTING

[-- Attachment #2: R_Zimmermann.vcf --]
[-- Type: text/x-vcard, Size: 427 bytes --]

begin:vcard
fn:Dr. Roger Zimmermann
n:Zimmermann;Dr. Roger
org;quoted-printable;quoted-printable:Zentrum f=C3=BCr exp. Medizin;Institut f=C3=BCr Neuro- und Pathophysiologie
adr;quoted-printable:;;Martinistra=C3=9Fe 52;Hamburg;;20246;Germany
email;internet:R.Zimmermann@UKE.Uni-Hamburg.de
tel;work:..49 (0)40 42803 5351
tel;fax:..49 (0)40 42803 7255
x-mozilla-html:FALSE
url:http://www.uke.uni-hamburg.de
version:2.1
end:vcard