On Sun, 11 Aug 2019 13:36:39 +1000 Daniel Kasak <d.j.kasak...@gmail.com> said:
hey hey :) > Hi there. I'm a long-time E user, and I'm looking to add some functionality > around mouse configuration. I'm a developer with stacks of 4GL experience, > and "not much at all" experience with C - the extent of my work so far has > been patching some gtk+ bugs, and that was *years* ago. > > I've been reading up on libinput. I've studied the patch that added > tap-to-click support, and made some notes of what would be required to add > custom button mappings and "on button scrolling". I've found the place 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. 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). it's quite possible support code may need to go into elput or ecore_x in efl if the support code is not there already as well. > where E maps button events based on whether a left or right -handed profile > is set. I see that this is a global thing - or at least there doesn't > appear to be any per-device configuration. I've found the configuration > stuff in enlightenment/src/bin/e_config.c, but these are just key/value > pairs, right? 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. it's basically a little bit of sugar around eet which does the "hard work" of actually encoding and decoding, compressing.recompressing from the cfg files to handle fallbacks if a decode fails (the backup config files) as well as just to declare the structure content and types to eet, queue up a save for the future (so config changes save out but we aren't continually again and again - we defer the saves for a bit thus baching them up into a single one). so basically... if you can express it in a c struct, it can be encoded and decoded from config. that allows for complex data structures. so it may look key-value pair because it's actually giving types to eet (this struct needed encoding and struct member X of type int needs to be encoded, struct member Y of type unsigned char needs encoding, this other member of type string (char *) needs encoding ... etc.) as well as just a default set of values to put in the struct before e has loaded any config at all. these compiled in defaults are intended to be nothing more than barebones minimums to allow e to then be able to go load something. > 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. > 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? 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. 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. :) > 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? 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. :) at this point... i pass off to devilhorns for the details :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
