Re: Input handling

[Tadas Dailyda <tadas dailyda com>]

Hi Nicolas,

Nice to know that you are doing some work for bluez-gnome too. I will
write my patch for bluetooth-applet soon to expose OBEX Object Push and
OBEX FTP functionality.

My recommendation would be not to mess with vala when doing D-Bus
service. It was quiet some pain to do it in C for me and there were many
odd things to figure out about DBus glib bindings. Personally I wouldn't
try doing it with Vala.


Cheers,
Tadas Dailyda

On Thu, 2007-08-16 at 12:32 +0200, Nicolas Trangez wrote:
> A little summary of what I've been doing lately:
> Avivo
> -----
> Fix avivo on ATI X1600 (necessary to be able to run xserver-git),
> including some little fixes for avivotool
> 
> Bluez-Gnome
> -----------
> I had some troubles figuring out how to do the "add bluetooth mouse"
> thing UI-wise, the bluetooth-wizard in bluez-gnome seems to be the way
> to go.
> First I made a patch to the applet so BT devices could be whitelisted on
> a per-address base (before it was all or nothing). Once submitted I was
> told this was already implemented in bluez-libs, bummer.
> The code of b-w isn't very nice though, so I discussed this with Marcel
> Holtmann, and decided to rewrite it using Vala. I did rewrite the UI,
> but the whole application doesn't work yet as I need to be able to
> implement a DBus service in Vala, which is (at the moment) not trivial,
> which brings us to the next point.
> 
> Vala
> ----
> While working on the vala version of b-w, I ran into some valac bugs. I
> reported these to bugzilla as at the time I wasn't familiar with the
> valac codebase (compiler code isn't that easy :s). I wrote a patch to
> allow adding .c source files to the valac command line (useful during
> testphases when you got no autofoo setup done yet).
> Then I started working on functionality to write DBus services using
> vala. Before doing this I fixed the "make distcheck" target, which
> included implementing the "--directory" command line option of valac,
> which was there but was a no-op, and rewriting the testcases system.
> Patches are in bugzilla and will be reviewed by Jürg.
> I'm still working on the "writing DBus services" thing so the vala b-w
> version can be finished, but it's not trivial.
> 
> XServer
> -------
> Once I got avivo working and was able to run xserver-git, the
> hotplugging stuff did work. There were some issues with the initial
> version though, especially on input device driver selection. The driver
> to use is set using a HAL FDI file, which results in the
> input.x11_driver property.
> When discussing this with Daniel some problems came up, the most
> significant one the fact there could be only one driver defined per
> device. This could be a problem, eg: you got the standard xserver fdi
> file installed, which results in evdev being used, but you haven't got
> the evdev X driver installed. Your devices won't work.
> So I re-implemented this part using a strlist instead of one string,
> providing a fallback mechanism.
> Once this was done some other issues came to mind: the fact we ship the
> FDI file with the Xserver package, which is not logical (they should be
> provided by the driver packages), and the fact a strlist got no real
> "order", the order depends on the order the FDI files are parsed.
> I came up with the idea to change the normal "drivername" strings to
> "priority:drivername", so we'd have a strlist of drivers to try,
> including some priority (eg "5:synaptics", "10:evdev" and "20:mouse" for
> input.touchpad devices). I implemented this behaviour too. Patch for
> this and the previous topic were sent to the list, but code retention
> period started today so I don't know whether it'll get in.
> One more issue to tackle here is adding a way to provide arbitrary
> options to the driver when a new X device is created, eg. ZAxisMapping,
> SHMConfig (for synaptics), etc. I implemented a way to achieve this, but
> it needs more testing before I submit it.
> 
> ACPI4Asus
> ---------
> In modern Linux-land, daemons like acpid to relay ACPI-based hotkey
> events to the kernel by pulling them into userspace, then injecting them
> into the input layer should no longer be used. Most in-kernel
> vendor-specific ACPI drivers with hotkey functionality (sony, thinkpad,
> toshiba) were already converted to provide their own event/input device
> so hotkey events were directly handled to the input layer, no longer to
> the ACPI subsystem. The asus-laptop driver wasn't converted yet though
> (and I'm an Asus owner), so I wrote a patch to implement this. Now
> hotkey events are no longer sent to /proc/acpi/events, but handled by a
> new input device, "Asus Extra Buttons".
> I did not add a scancode-to-keycode map to the driver though, setting
> this is done completely from userspace using ioctl's on the device. HAL
> got functionality to set these mappings based on FDI files. I wrote an
> FDI for my laptop model, sent to the list.
> As this requires a very new HAL version (or some people might not like
> HAL) I also wrote a little application to set these mappings, mainly for
> testing purposes. I passed both the patch and the app to some Asus
> owners I know, who tested it (and were pretty happy with the
> result ;-)). Some more FDI files should be sent to the HAL list in the
> near future by them.
> I blogged some more info about this, maybe you read that.
> 
> That's it for now. When I run xserver-git with the free avivo driver
> using "AllowEmptyInput true" in my xorg.conf, and no input devices
> specified, my touchpad and keyboard work (even when I remove the evdev
> driver because of the fallback mechanism), when plugging in a USB mouse
> it works too, including all buttons and scrollwheel.
> When I add my BT mouse in bluetooth-preferences (UI-wise not so
> great :s) it gets detected and almost immediately works too. When I
> registered it once it directly works in later sessions too.
> 
> TODO for the coming days/weeks is the driver-specific xserver options in
> HAL (almost finished) and the ability to write DBus services in vala
> (will take a while). One future project I'd like to do is a service
> (like g-v-m) which acts on hotkey button presses, centralized. Some
> examples: eject my cd tray when KEY_EJECTCLOSECD is pressed, maybe the
> volume changing code could go in here too, integrate the "change
> monitor" button with the randr1.2 tool, same for KEY_TV, add
> functionality for the "performance" button (eg get wlan chipset or gpu
> in low-power mode), make the "disable touchpad" button actually disable
> the touchpad, etc. This will be a september project though.
> 
> 
> Overall feeling
> ---------------
> There's one thing I realized pretty well last weeks: it's *much* easier
> to write "your own" project (where you're the maintainer) than working
> on projects maintained by others when you got deadlines. Sometimes it's
> really frustrating if you have to wait before you can progress for code
> pushes by someone else (and it seems like the whole distributed scm
> model make people push changes less frequently as they just work on
> their private branch :(), if you implement some functionality and don't
> get any review of it for several days (if you get any review at all, I
> didn't get any answer on several patch mails I sent yet) so you don't
> know how to proceed, etc. When working on your own project it's much
> easier to move on.
> Anyway, that's not a complaint at all, just an observation :-)
> 
> 
> Nicolas
> _______________________________________________
> gnome-soc-list mailing list
> gnome-soc-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-soc-list