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
Attachment:
signature.asc
Description: This is a digitally signed message part