Hi Roger, On Thu, Jan 30, 2014 at 10:25 AM, Dr. Zimmermann <R.Zimmermann@xxxxxxxxxxxxxxxxxx> wrote: > Or is there a better forum to ask about X (input) stuff? xorg list (added) would definitely be a better place to discuss this topic. > 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? > The next steps would be to read events through xinput, that is, instead of consuming event from your GUI toolkit, retrieve them directly from X. ( It may exist supporting tool for that). Main steps are * retrieve a display, (XOpenDisplay) * retrieve your device based on name (oR id), (XIQueryDevice ) * bind your display with some events of your device, (XISetMask, XISelectEvents ) * retrieve a file descriptor for your display event, feed your mainloop with this file descriptor (ConnectionNumber) * read and decode event (XPending, XNextEvent, XGetEventData) Here is an example tool relaying xinput events to a software bus you may find interseting to throw a glance: http://svn.tls.cena.fr/wsvn/ivy/xinput2-ivy/trunk/xinput2_ivy.c I do not see the need for another pointer/keyboard (that would not be core by the way) unless you use a tool that support multiple keyboard (I know of no such tool). Regards, Fabien On Thu, Jan 30, 2014 at 10:25 AM, Dr. Zimmermann <R.Zimmermann@xxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> wrote: >>>> >>>>> Am 28.01.2014 12:15, schrieb David Herrmann: >>>>> >>>>> Hi >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 11:20 AM, Dr. Zimmermann >>>>>> <R.Zimmermann@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
