Thanks! Also ... yikes! So the short version is that this is significantly
more work than I'd imagined :/
On Sun, Aug 11, 2019 at 9:54 PM Carsten Haitzler <ras...@rasterman.com>
wrote:
> On Sun, 11 Aug 2019 13:36:39 +1000 Daniel Kasak <d.j.kasak...@gmail.com>
> said:
> aaah please note: libinput (via elput) is for wayland mode (or specifically
> wayland mode when targetting drm/kms (framebuffer/tty) as the target). it
> is
> not for x11.
OK. I hadn't given this much thought, other than a blind assumption that
libinput *would* work for x11. That complicates things.
so there needs to be a consideration of making the wayland
> support on par with x11 vs adding new features where both paths then need
> the
> support (if it is possible, and if it is not finding an appropriate way of
> dealing with that situation).
Well making everything work the same way - with libinput - might be an easy
way to achieve this? I assume there are reasons why we can't do this?
actually no - e_config is a full data struct. it can contain linked lists,
> sub
> structs, arrays - look at anything with E_CONFIG_LIST macros declaring
> them.
>
OK great :)
> This is where I'm not sure how I would proceed ... ie how would I go about
> > defining a per-device configuration for things like button mappings? Can
> I
> > store a config structure against a key ( maybe not I guess ), or a list?
>
> in any way you like - but generally since devices are N - probably a
> linked list
> of structs. each struct has some way to identify the device again at
> runtime
> (map it to the device info e.g. by name? so string(s) (perhaps multiple).
> you
> want to choose a way to map it that will work across systems that have the
> same
> device plugged in or across boots/sessions so perhaps device id's is bad...
> classes of device will be constant as will probably be manufacturer
> identifier
> strings, serial numbers provided by the hardware itself etc. -> look at the
> randr config data. there is a list of configured screens and the code thee
> uses
> a combination of gfx card output name (DP0, HDMI-1, etc.) and the edid
> data. to
> the randr code this is considered a unique combination (THAT monitor
> plugged
> into THAT port). so if that combo is seen again the existing config saved
> in a
> list is applied next time - so plug a screen in once, configure it, unplug
> it,
> plug it in the next day and it will do exactly what it did last time.
>
Got it.
> I also have no idea of how I'd determine what device was the source of an
> > event.
>
> now you begin to hit the problems. :) you need to do this for both x11 AND
> wayland i think. you probably need to expand on what you are trying to
> achieve
> here. i am guessing you want things like "if i have 2 keyboards plugged in
> and
> i press escape on the logitech one over there but not escape on the clanky
> ibm
> ps/2 kbd here... i want THAT escape key press to do something different",
> or
> same with 2 mice, or a mouse + trackball or 21 active pen devices on a
> touchscreen?
>
Well for me personally, it's just to remap some buttons on my trackball.
The 1st button is dying from being clicked many times. I map one near it to
be button 1. I wouldn't want this mapping to be global, as it would screw
up my laptop touchpad's 1st button. I also set up the ScrollButton feature,
using this xorg.conf fragment:
Section "InputClass"
Identifier "Logitech USB Receiver"
MatchProduct "Logitech"
Option "SendCoreEvents" "True"
Option "ButtonMapping" "8 2 3 4 5 6 7 1 9 10 11 12"
Option "ScrollMethod" "button"
Option "ScrollButton" "10"
Option "Tapping" "on"
EndSection
> for x11 there are core events where you basically have no idea where it
> comes
> from. a mouse button 1 press is a mouse button 1 press. you don't know what
> device produced it. same with keys. all our bindings setup is built around
> this
> generic "i got an event but its generic" set of events.
>
So libinput under x11 doesn't allow the kind of per-device config as per
above? That's harsh.
there is an x extension called xinput. ecore_x_xi2.c in efl deals with
> xinput
> 2.x ... it mostly abstracts touch events so we can get multitouch data.
> xinput
> events have far more extensive info like device id ... which you can then
> track
> back to some device data like a name (just run the xinput commandline tool
> to
> see what devices you have plugged in and some names - this just uses the
> xinput
> extension to query this from x).
>
> now elput is the interface to this (on top of libinput) and it wraps up
> libinput and hides a bunch of details and glues it into the mainloop etc.
> cutting down the code needed in e to deal with it (and thus sharing that
> wrapper with efl too so efl apps work directly in the tty too via the same
> elput wrapper). elput exposes Elput_Device's - you get events when they
> plug
> and unplug and you can query device capabilities, name etc. so in many
> ways it
> looks like the xinput part of xlib/ecore_x. if you want something more
> extended
> you need to look into this as well as xinput and ecore_x and come up with
> a way
> of both being equivalent. elput still will need some filling in here to tag
> events it posts to the event queue (ecore_event_add()) with the correct
> device
> identifiers (evas devices) etc. etc. ... yes - it slooks complex. it's a
> result
> of years of evolution of the api where it went from wanting to just work
> on x11
> to being able to work in the fb (fbcon) to then working on windows and osx
> too
> and wayland and e becoming a wayland compositor etc. as well as efl having
> been
> split into all these libraries and layers. it'd have been a lot simpler if
> it
> were designed from day 0 with this all in mind and as a single library and
> not
> a whole bunch of them. :)
>
I see. I'm not overly confident that I'm up to that part :)
> > If someone can give me some pointers / examples ... I *might* be able to
> > add support for per-device mouse configuration, which I think would make
> > the experience on wayland much nicer :)
>
> so you just want to CONFIGURE the mice in wayland mode right?
Yes :)
then elput has
> the api you need to deal with and elput is probably going to need extended
> api's to configure elput devices - specifically the way you want. reality
> is...
> ecore_x+xinput needs this too so you will have to consider both paths. :)
> both
> will need extending and any data structs in e need to then probably be
> generic
> enough to span both use cases. :)
>
I'll look more at this then. As noted above, it seems like the task is
significantly more complicated than I had 1st imagined, and maybe biting
off too much for a 1st serious attempt at doing anything in C. Maybe it
would make sense to tackle some other low-hanging fruit and return to this
when I'm a but more familiar with things. I'll see ...
Thanks for your in-depth response :)
Dan
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
