If you're tempted to add a platform-specific quirk to a Linux driver, pause and do the following:

1. Check whether the platform works correctly with the generic Windows driver for the hardware in question. If it requires a platform-specific driver rather than the generic one, adding a quirk is probably ok.
   
2. If the generic Windows driver works, check whether there's any evidence of platform-specific code in the Windows driver. This will typically be in the .inf file, but occasionally you'll want to run strings against the Windows driver and see whether any functions or strings match the platform in question. If there's evidence of special-casing in the generic Windows driver, adding a quirk is probably ok
   
3. If the generic Windows driver works and doesn't appear to have any platform-specific special casing, don't add a quirk. You'll plausibly fix the machine you care about, but you won't fix any others that have the same behaviour. Even worse, if someone does eventually fix the problem properly, there's a risk that your special-casing will now break your system.

The moral to this story is: if you think adding a quirk is the right solution, you're almost certainly wrong.

comments

This hasn't been my week. I had to fix two of my Hurd installations I use for development and testing. I spent countless hours waiting for some package to be rebuilt, reading scientific papers about adding stuff to the Mach kernel. Fascinating stuff like thread migration that would (among other things) allow for proper resource accounting on Mach kernels. Oh, and gcc is a sadistic bastard:

In file included from printf-parsewc.c:2:0:
printf-parsemb.c: In function  __parse_one_specwc :
printf-parsemb.c:407:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

A similar error came up like five hours into my libc rebuild. How nice of gcc to retry the build to figure out whether it is to blame or the environment only to throw away the successful build and abort my build process :/

• I published my patch series addressing all sysvinit-related issues: http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00000.html
• I since found three minor issues, so I'll roll another series shortly. But since this somewhat breaks the ABI (/hurd/init is no longer PID 1) this is waiting for a libc rebuild that I haven't managed to get done so far.
• I updated my patch series for the sysvinit package. I'm quite pleased with it as it is and I'll propose it for inclusion with the sysvinit package shortly. Unfortunately this depends on the patched hurd package with is blocked by the libc package :/

Next week I'll finally propose my sysvinit patch series. Oh, and implement the -d flag in our umount. I thought I had implemented all the flags used by the initscripts, but somehow I missed -d. If I get bored, I'll take a look at the network related issues, but I bet I won't get there...

So... Well, contrary to the popular sentiment in Planet Debian, this year I'm very sorry to inform that... This is the first DebConf I miss in ten years, so... Yes, it's a big bummer for me. I'm not attending because this year, DebC(amp onf) coincide with the two first weeks of classes at my university And as a new teacher, I cannot afford to miss it! Anyway, but that should not stand in the way to attend a nice Debian 20th anniversary party! Parties will be held around the world. (Didn't find your city? Plan something and add it *now!*). In Mexico City, the nice guys at the very interesting Rancho Electr nico hackerspace took the lead, and organized the following activities: Don't you yet know the hackerspace? You should go there! It's in a very centric location, just two blocks West from Metro San Antonio Abad (Juan Lucas Lassaga 114, col. Obrera). And the only two times I have been there, it has been good fun. Surely this Saturday we can have a nice party as well! The planned activities are from 13:30 to 20:30. See you there!

As a more or less random data point for DebConf13, here's the current bug stats for Debian. Hope to see you there, and if you want to attend the BoF Gitify ALL the things or the talk Gitify your life you can do so on site, via IRC in #vcs-home on OFTC, or simply follow the live streams. If you see my in person, I have two crates of Scheider Aventinus with me and don't plan on bringing home any full bottles. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1532
  • Affecting Jessie: 1019 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 832 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 51 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 38 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 743 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 187 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 0 bugs are in packages that are unblocked by the release team.
      • 187 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

A minor maintenance release of inline is now on CRAN, and has just been already included in Debian. This release contains a patch kindly contributed by Mikhail Umorin which fixes the of \code cfunction with lists of signatures and function bodies. The complete NEWS entry is below.

Changes in inline version 0.3.13 (2013-08-08)

• Applied contributed patch by Mikhail Umorin which corrects cfunction() in the case of a list of signature and body arguments.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. A few more details are available at the R-Forge page.

pidof is a program that finds the PID of a named program. In some ways it is like a cut-down pgrep found in the procps package. pidof currently sits in sysvinit-tools. There are plans to move all utilities that use the proc filesystem under one package which will make the maintenance of them simpler, which in effect means moving pidof from sysvinit-tools to procps. The short-term bump should make it better in the long term. Now as I wear two hats (Debian maintainer and procps upstream) there are two very important things I/we need to know.

• If your Debian package depends on pidof being present, then we need to discuss dependencies. procps is generally installed on most systems but there might be corner cases. Possibly just depending on a specific version of procps will do it
• If you, your Debian package or anything else (including other distributions) need the non-LSB options of pidof (ie they use -c -n or -m) then we (upstream) need to know about it. There are provisional plans not to support these options but they re needed, or a subset is, then that could change.

Debian developers can chime in on the debian-devel email list, or email myself. If its an upstream issue then either email me, or even better, the procps email list

pidof is a program that finds the PID of a named program. In some ways it is like a cut-down pgrep found in the procps package. pidof currently sits in sysvinit-tools. There are plans to move all utilities that use the proc filesystem under one package which will make the maintenance of them simpler, which in effect means moving pidof from sysvinit-tools to procps. The short-term bump should make it better in the long term. Now as I wear two hats (Debian maintainer and procps upstream) there are two very important things I/we need to know.

• If your Debian package depends on pidof being present, then we need to discuss dependencies. procps is generally installed on most systems but there might be corner cases. Possibly just depending on a specific version of procps will do it
• If you, your Debian package or anything else (including other distributions) need the non-LSB options of pidof (ie they use -c -n or -m) then we (upstream) need to know about it. There are provisional plans not to support these options but they re needed, or a subset is, then that could change.

Debian developers can chime in on the debian-devel email list, or email myself. If its an upstream issue then either email me, or even better, the procps email list

Weblate 1.6 is already two weeks out without any regressions, so now it's time to think about features for 1.7. I definitely want to improve support for monolingual translation formats as they currently suffer by various metadata issues (eg. checks not working correctly). This requires quite big change in underlying database, but I think it's quite manageable. When talking about checks, I want to make them configurable per project as global configuration is quite limiting for shared sites like hosted Weblate. I will definitely need to touch registration and authentication, either by supporting latest django-registration API or to move some other solution with support for federated login. Which of these approaches will be used depends on my time, what is always the most limiting factor. This might sound as too few features, but I'd like to make releases more often, so that should fit into this plan. However if you want to push for some feature, you still have two days to fund something on Catincan!

Filed under: English Weblate 0 comments Flattr this!

I've just pushed out the release files for Obnam version 1.5, my backup application, and Larch, my B-tree library, which Obnam uses. They are available via my home page (http://liw.fi/). These versions have alos been uploaded to Debian unstable. NEWS for Obnam:

• Terminal progress reporting now updated only every 0.1 seconds, instead of 0.01 seconds, to reduce terminal emulator CPU usage. Reported by Neal Becker.
• Empty exclude patterns are ignored. Previously, a configuration file line such as "exclude = foo, bar," (note trailing comma) would result in an empty pattern, which would match everything, and therefore nothing would be backed up. Reported by Sharon Kimble.
• A FUSE plugin to access (read-only) data from the backup repository has been added. Written by Valery Yundin.

NEWS for larch:

• Bug fix in how Larch handles partly-comitted B-tree journals in read-only mode. Previously, this would result in a crash if, say, a node had been removed, but the B-tree metadata hadn't been committed.

Small update as someone was complaining about the lack of pictures from DebCamp on planet. Not to worry, everything is going fine, and some of the most important stuff is ready You can see a few pictures from the gallery. The view from the venue is quite outstanding (it was better when there was some sun on Tuesday, but my camera battery was out ). On my TODO-list:

• A lot of mentors.d.n related stuff : prototyping things to make our codebase more bearable by actually using other people s work, e.g. debianqueued, firehose, , and building upon Lucas s idea from his new contributor survey (see the quite vague idea at the bottom)
• FedMsg stuff (will probably pick up when Simon arrives)
• Some 3D-printing packaging stuff (actually getting software in NEW, I got started on Printrun, and maybe Slic3r)

See you there!

I will arrive at DebConf 2013 on Sunday afternoon. In case you are interested in Go (the programming language), systemd, i3 or getting your package reviewed, please talk to me! :-) Looking forward to meeting many of you in real life.

With the number of female software engineers standing at 20.9% [1], recruitment of females into the industry is a major concern. A friend of mine, Rosemary Francis who's MD of Ellexus, has a great talk about this issue. It mentions various methods you can use to tailor your job applications to be more attractive to females, by simply being careful not to exclude or put off potential applicants. However, there is also a very poor way of doing so, which is highly sexist and plays to stereotypes. As we can see from Bloopark's hiring page, this is exactly what they have done.

Web developer (m)
Need for programming
You are addicted to PHP, MySQL and Javascript since years? Your life makes no sence without programming? Your girlfriend doesn't understand, why you start learning the fifth php framework and your parents say, your head is full of unix and linux. Do you want to talk to us about this? We want to invite you to an anonymous or maybe very personal meeting. No worries, we will bring you to a team that understands you and will support your passion of programming. Web developer (f)
Beautiful und sexy code wanted
We are convinced that woman are great programmers. Woman write sexy code: neat and clean. Many of them have long relationship... with PHP5, MySQL and Javascript. They like to talk and communication is essential in our work. Female programmers get along with customers very well and take such a good care of code quality, as if it is a pair of their new shoes. The best thing is that their detailed documentation and code organisation match the rules of Feng-Shui. Are you a female programmer with passion? May we invite you for coffee?

Really? New pair of shoes? Pictures of nail varnish? They're in a relationship with code? And why does the male version need to have a girlfriend rather than a boyfriend? [1] US Bureau of Labor Statistics (BLS) - ftp://ftp.bls.gov/pub/special.requests/lf/aa2010/aat11.txt

I recently had to migrate the main Libravatar server to a new virtual machine. In order to minimize risk and downtime, I decided to write a migration plan ahead of time. I am sharing this plan here in case it gives any ideas to others who have to go through a similar process.

Prepare DNS

• Change the TTL on the DNS entry for libravatar.org to 3600 seconds.
• Remove the mirrors I don't control from the DNS load balancer (cdn and seccdn).
• Remove the main server from cdn and seccdn in DNS.

Preparing the new server

• Setup the new server.
• Copy the database from the old site and restore it.
• Copy /var/lib/libravatar from the old site.
• Hack my local /etc/hosts file to point to the new server's IP address:

  xxx.xxx.xxx.xxx www.libravatar.org stats.libravatar.org cdn.libravatar.org
  

• Test all functionality on the new site.

Preparing the old server

• Prepare a static "under migration" Apache config in /etc/apache2/sites-enables.static/:

  <VirtualHost *:80>
      RewriteEngine On
      RewriteRule ^ https://www.libravatar.org [redirect=301,last]
  </VirtualHost>
  <VirtualHost *:443>
      SSLEngine on
      SSLProtocol TLSv1
      SSLHonorCipherOrder On
      SSLCipherSuite RC4-SHA:HIGH:!kEDH
      SSLCertificateFile /etc/libravatar/www.crt
      SSLCertificateKeyFile /etc/libravatar/www.pem
      SSLCertificateChainFile /etc/libravatar/www-chain.pem
      RewriteEngine On
      RewriteRule ^ /var/www/migration.html [last]
      <Directory /var/www>
          Allow from all
          Options -Indexes
      </Directory>
  </VirtualHost>
  

• Put this static file in /var/www/migration.html:

  <html>
  <body>
  <p>We are migrating to a new server. See you soon!</p>
  <p>- <a href="http://identi.ca/libravatar">@libravatar</a></p>
  </body>
  </html>
  

• Enable the rewrite module:

  a2enmod rewrite
  

• Prepare an Apache config proxying to the new server in /etc/apache2/sites-enabled.proxy/:

  <VirtualHost *:80>
      RewriteEngine On
      RewriteRule ^ https://www.libravatar.org [redirect=301,last]
  </VirtualHost>
  <VirtualHost *:443>
      SSLEngine on
      SSLProtocol TLSv1
      SSLHonorCipherOrder On
      SSLCipherSuite RC4-SHA:HIGH:!kEDH
      SSLCertificateFile /etc/libravatar/www.crt
      SSLCertificateKeyFile /etc/libravatar/www.pem
      SSLCertificateChainFile /etc/libravatar/www-chain.pem
      SSLProxyEngine on
      ProxyPass / https://www.libravatar.org/
      ProxyPassReverse / https://www.libravatar.org/
  </VirtualHost>
  

• Enable the proxy-related modules for Apache:

  a2enmod proxy
  a2enmod proxy_connect
  a2enmod proxy_http
  

Migrating servers

• Tweet and dent about the upcoming migration.
• Enable the static file config on the old server (disabling the Django app).
• Copy the database from the old server and restore it on the new server.
• Copy /var/lib/libravatar from the old server to the new one.

Disable mirror sync

• Log into each mirror and comment out the sync cron jobs in /etc/cron.d/libravatar-slave.
• Make sure mirrors are no longer able to connect to the old server by deleting /var/lib/libravatar/master/.ssh/authorized_keys on the old server.

Testing the main site

• Hack my local /etc/hosts file to point to the new server's IP address:

  xxx.xxx.xxx.xxx www.libravatar.org stats.libravatar.org cdn.libravatar.org
  

• Test all functionality on the new site.
• If testing is successful, update DNS to point to the new server with a short TTL (in case we need to revert).
• Enable the proxy config on the old server.
• Hack my local /etc/hosts file to point to the old server's IP address.
• Test basic functionality going through the proxy.
• Remove local /etc/hosts/ hacks.

Re-enable mirror sync

• Build a new libravatar-slave package with an updated known_hosts file for the new server.
• Log into each server I control and update that package.
• Test the connection to the master (hacking /etc/hosts on the mirror if needed):

  sudo -u libravatar-slave ssh libravatar-master@0.cdn.libravatar.org
  

• Uncomment the sync cron jobs in /etc/cron.d/libravatar-slave.
• An hour later, make sure that new images are copied over and that the TLS certs are still working.
• Remove /etc/hosts hacks from all mirrors.

Post migration steps

• Tweet and dent about the fact that the migration was successful.
• Send a test email to the support address included in the tweet/dent.
• Take a backup of config files and data on the old server in case I forgot to copy something to the new one.
• Get in touch with mirror owners to tell them to update libravatar-slave package and test ssh configuration.
• Add third-party controlled mirrors back to the DNS load-balancer once they are up to date.
• A few days later, change the TTL for the main site back to 43200 seconds.
• A week later, kill the proxy on the old server by shutting it down.

Getting new Front Desk members (part of things to do at Debconf) We need more Front Desk members. Jonathan Wiltshire has kindly put together a job description for the current status quo. Currently we'd like a person to have been an Application Manager before joining Front Desk, but FD tasks are now more diverse than they used to be, and I'd like to spend some time thinking about it, for example here. Job Description for Front Desk Assistant Front Desk assistants are often the first point of contact for new applicants to Debian's New Member process, and are responsible for guiding them through all stages. Front Desk collates applications, assigns them to an Application Manager, checks over the completed application and hands it off to the Account Managers. Front Desk also handles membership of the collab-maint Alioth project. It is not currently involved with applications for Debian Maintainer status. You will 'meet' a wide variety of applicants, some of whom are excited to be starting their journey to Debian membership, whilst others are already established and taking the next step to full developer status. This is a mostly procedural role, but some diplomatic skills are required, particularly when applications are held up for reasons beyond your control. You must have excellent written communication, an eye for detail, and a thorough understanding of what it is to be Debian Members. Expect to spend 2-3 hours per week on this role, divided by as many days as you can manage (to ensure mail is dealt with as soon as possible). The most time-consuming part is processing the completed application. Responsibilities:

1. To be the first point of contact at Front Desk
2. To perform initial triage of applications
3. To match each application with an appropriate Application Manager
4. To ensure applicants are processed in a timely manner, which may require intervening with an application when it is not progressing satisfactorily
5. To check completed applications for any missing detail and pass them on to the Account Managers
6. To handle collab-maint membership business
7. To answer any queries from applicants, Application Managers, and other stakeholders
8. To monitor output from the NM routine jobs and fix or escalate any problems

Front Desk staff are not expected to make a judgement call on applicants, though some discretion can be used when appropriate.

Choosing Embedded Processors for AltOS When Bdale and I started building rocketry hardware together, we had already picked out a target processor, the TI cc1111. We picked that chip almost entirely based on the digital transceiver that is built in to the chip, and not because we had any particular love for the 8051 microcontroller. At that time, I d seen people struggle with PIC processors, battle AVR to a draw and spend a lot of time trying to get various ARM processors running. So, the 8051 didn t seem all that far from normal, and the cc1111 implementation of it is pretty reasonable, including credible USB support and a built-in DMA engine. Since those early days, we ve gone on to build boards with a slightly wider range of processors:

• TI cc1111
• Atmel ATmega32U4
• Atmel ATiny85
• STMicroelectronics STM32L151/STM32L152
• NXP LPC11U14

Bdale thinks we should reduce the number of components we use to focus our efforts better. He s probably right, but I have to admit that I ve had way too much fun getting each of these chips running. I thought I d spend a bit of time describing our general process for selecting a new CPU.

• Free software. I m long past the age at which I trust hardware vendors to deliver credible binary software. If you want me to use your silicon, make sure the tools required to use it are all free software.
• Debian support required. Bdale and I do everything on Debian, so any processor we use needs to have tools that run under Debian. We re more than willing to package software for Debian, so if it s just generic Linux-compatible free software, that s fine.
• Built-in USB. Everything we build needs to talk to a computer for configuration and data download. Don t even think of asking me to attach another chip for USB support. Ok, so the ATtiny85 doesn t qualify here, and that project does use an external chip for USB which is connected to the ATtiny85 through an LED and phototransistor. I was excited when TI came out with the CC340 chips because the MSP430 is a much nicer CPU than the 8051. But, they still haven t added USB. If I m going to add another chip for USB, it ll be a CPU anyways, at which point I ll use a stand-alone RF chip.
• Cheap developer boards. TI sells a tiny little cc1111 developer board; STmicroelectronics and NXP both sell boards that include a programmer and a target CPU for prototyping software. And, there are a million Arduino clones with various Atmel processors on them. Cheap means I can buy them without thinking too hard; having a built-in programmer means that early OS development can be done without first having to figure out how to wire up a programmer.
• Probably 32 bits, probably an ARM. Yeah, the cc1111 and Atmel processors were fun to bring up, but I m pretty much over the 8-bit microcontroller now. ARM processors are far more sophisticated in terms of power management and built-in device capability, plus they re a ton faster at doing any math. The ATtiny85 remains an exception here; it s smaller than any ARM I can get, and so it s still useful for projects too small for an ARM.
• Available in small quantities from a reasonable on-line retailer like Digikey, Mouser or even Avnet Express. I d love to try out the new low-cost STM32L100 parts, but the only one available is the largest one in the 64LQFP package, and I really don t need that many pins for most products.

CC1111 involved a lot of software hacking The 8051 processor in the CC1111 is very well documented, including the two-wire debugging interface. What was missing was a canned solution for programming and debugging the chip from Debian. However, with sufficient motivation and accurate docs, I was able to create a programmer from a USB device with a couple of GPIOs and a lot of ugly software on Linux. That sufficed to get the USB stack limping along, at which point I wrote a much faster programmer that ran on the cc1111 itself and could program another cc1111. With that, I created an assembly-level debugger that could be hooked to the existing SDCC source level debugger and had a full source-level debugging environment for the 8051. This turned out to be way better than what I could get on the Atmel processors, where I ve got a program loader and a whole lot of printf debugging. STM has been great The STM32L-Discovery board has a standard STM debugging setup for the Cortex SWD interface right on the same board as a target CPU. That made for completely self-contained development, with no jumper wires (a first for me, for sure). There s free software, stlink which can talk over the debugger USB connection to drive the SWD interface. This is sufficient to flash and debug applications using GDB. Of course, GCC supports ARM quite well; the only hard part was figuring out what to do for a C library. I settled on pdclib, which is at least easy to understand, if not highly optimized for ARM. We ve built a ton of boards with the STM32L151 and STM32L152; at this point I m pretty darn comfortable with the architecture and our tool chain. Adventures with NXP The NXP LPC11U14 is a very different beast. I m using this because:

• It s small (5mm x 5mm)
• It s cheap ($1.48 q100)

The LPCXpresso board looks much like the STM32L-Discovery, with a debugger interface wired to the CPU directly on the board. However, I haven t found free software tools to drive this programmer; all I ve found are binary-only tools from NXP. No thanks. Fortunately, the LPC11U14 uses exactly the same SWD interface as the STM32L, so I was able to sever the link between the programmer and the target on the LPCXpresso board and hook the target to an ST-Link device (either the one on the STM32L-Discovery board, or the new stand-along programming dongle I bought). With that, I wrote an openocd script to talk to the LPC11U14 and was in business. What I found in the NXP processor was a bit disturbing though there s a mask ROM that contains a boot loader, which always runs when the chip starts, and a bunch of utility code, including the only documented interface to programming the flash memory. I cannot fathom why anyone thought this was a good idea I don t want a BIOS in my embedded CPU, thankyouverymuch; I d really like my code to be the first instructions executed by the CPU. And, any embedded developer is more than capable of programming flash using a register specification, and calling some random embedded code in ROM from the middle of my operating system is more than a bit scary. NXP could do two simple things to make me like their parts a whole lot more:

• Publish the programmer source code. The programming dongle is a tool for selling your silicon, not a separate revenue stream. Publish the source under a free software license (GPL recommended, of course). We ll take it, make it better, and ensure that you get the changes back to help your other customers. It s a win-win plan.
• Document the flash programming registers. Yeah, I could probably disassemble the mask-rom bits that are on the chip, but I have better things to do with my time. Heck, go wild and document any other hidden bits in the silicon. Again, we re embedded developers, we don t like magic hardware hidden from view any more than PC developers like the BIOS and SMM.

Right now, I m hoping the STM32L100C6 parts become available in small quantities so I can try them out; they promise to be as cheap as the LPC11U14, but are better supported by free software and offer more complete hardware documentation. Yeah, they re a bit larger; that will probably be annoying.

Debconf TODO-list Friday evening (2013-08-09) I'll arrive at Debcamp. Here is my TODO list for Debcamp and Debconf:

• Debtags
  • Discuss disbanding the debtags-devel mailing list, possibly merging it into debian-project.
  • Recruit debtags tag reviewers now that there's a new tag review interface.
  • Find ways of having DDs moderate their own tags.
  • Comaintainers for debtags.debian.net.
  • Tags in debian/control, try to implement the plan discussed with ftp-masters long ago.
  • Make a new package debtags-data, dependency of debtags, so that there can be frequent releases of debtags-data as a binary-indep package.
• NM
  • Debian Contributors (addressing this issue).
  • Recruit new FD/DAM members.
  • Cleanup NM files and repositories, removing all the obsolete stuff.
  • Sync procedures with keyring-maint and DSA, to reduce or remove the need of manual maintenance to keep nm.debian.org, the keyring and LDAP in sync.
  • Marketing analysis and NM interaction (ask me about it in person, preferably when drunk).
  • I fail at handling returning DDs: that needs fixing. There should be an interface in nm.debian.org for people returning from emeritus.
  • How to stop bounce loops in nm alias addresses and still receive legitimate bounces. Alternatively, find a way to prevent germans from configuring their own mail servers :P
  • Cleanup and consolidate NM documentation.
  • Scale NM documentation down to "I want to help Debian, what should I do?" or at least point to the appropriate place that can handle that need.
• Packages and services
  • Consolidate mailing list: what am I doing as a moderator of pkg-python and pkg-italian?
  • Consolidate services: what am I maintaning? What is really needed? Luckily there's a list.
  • Consolidate packages: find comaintainers for the important ones, reduce dependencies
  • How to deal with bugs from team Mayhem (#715997...#716001): can we define a package as "needs to be run in a controlled environment"?

Tracking Cursor Position I spent yesterday morning in the Accessibility BOF here at Guadec and was reminded that one persistent problem with tools like screen magnifiers and screen readers is that they need to know the current cursor position all the time, independent of which window the cursor is in and independent of grabs. The current method that these applications are using to track the cursor is to poll the X server using XQueryPointer. This is obviously terrible for at least a couple of reasons:

• Keeps the system active at regular intervals, preventing power savings.
• Increased latency in mouse tracking the interval between polling calls limits the time resolution of the position information.

These two problems also conflict with one another. Reducing input latency comes at the cost of further reducing the opportunities for power saving, and vice versa. XInput2 to the rescue XInput2 has the ability to deliver raw device events right to applications, bypassing the whole event selection mechanism within the X server. This was designed to let games and other applications see relative mouse motion events and drawing applications see the whole tablet surface. These raw events are really raw though; they do not include the cursor position, and so cannot be directly used for tracking. However, we do know that the cursor only moves in response to input device events, so we can easily use the arrival of a raw event to trigger a query for the mouse position. A better plan? Perhaps what we should do is to actually create a new event type to report the cursor position and the containing window so that applications can simply track that. Yeah, it s a bit of a special case, but it s a common requirement for accessibility tools.

 
    CursorEvent
        EVENTHEADER
        detail:                    CARD32
        sourceid:                  DEVICEID
        flags:                     DEVICEEVENTFLAGS
    root:                      WINDOW
    window:                    WINDOW
    root-x, root-y:            INT16
    window-x, window-y:        INT16
 

A CursorEvent is sent whenever a sprite moves on the screen. sourceid is the master pointer which is moving. root is the root window containing the cursor, window is the window that the pointer is in. root-x and root-y indicate the position within the root window, window-x and window-y indicate the position within window . Demo Application Here s a short application, hacked from Peter Hutterer s part1.c

/* cc -o track_cursor track_cursor.c  pkg-config --cflags --libs xi x11  */
#include <stdio.h>
#include <string.h>
#include <X11/Xlib.h>
#include <X11/extensions/XInput2.h>
/* Return 1 if XI2 is available, 0 otherwise */
static int has_xi2(Display *dpy)
 
    int major, minor;
    int rc;
    /* We support XI 2.2 */
    major = 2;
    minor = 2;
    rc = XIQueryVersion(dpy, &major, &minor);
    if (rc == BadRequest)  
    printf("No XI2 support. Server supports version %d.%d only.\n", major, minor);
    return 0;
      else if (rc != Success)  
    fprintf(stderr, "Internal Error! This is a bug in Xlib.\n");
     
    printf("XI2 supported. Server provides version %d.%d.\n", major, minor);
    return 1;
 
static void select_events(Display *dpy, Window win)
 
    XIEventMask evmasks[1];
    unsigned char mask1[(XI_LASTEVENT + 7)/8];
    memset(mask1, 0, sizeof(mask1));
    /* select for button and key events from all master devices */
    XISetMask(mask1, XI_RawMotion);
    evmasks[0].deviceid = XIAllMasterDevices;
    evmasks[0].mask_len = sizeof(mask1);
    evmasks[0].mask = mask1;
    XISelectEvents(dpy, win, evmasks, 1);
    XFlush(dpy);
 
int main (int argc, char **argv)
 
    Display *dpy;
    int xi_opcode, event, error;
    XEvent ev;
    dpy = XOpenDisplay(NULL);
    if (!dpy)  
    fprintf(stderr, "Failed to open display.\n");
    return -1;
     
    if (!XQueryExtension(dpy, "XInputExtension", &xi_opcode, &event, &error))  
       printf("X Input extension not available.\n");
          return -1;
     
    if (!has_xi2(dpy))
    return -1;
    /* select for XI2 events */
    select_events(dpy, DefaultRootWindow(dpy));
    while(1)  
    XGenericEventCookie *cookie = &ev.xcookie;
    XIRawEvent      *re;
    Window          root_ret, child_ret;
    int         root_x, root_y;
    int         win_x, win_y;
    unsigned int        mask;
    XNextEvent(dpy, &ev);
    if (cookie->type != GenericEvent  
        cookie->extension != xi_opcode  
        !XGetEventData(dpy, cookie))
        continue;
    switch (cookie->evtype)  
    case XI_RawMotion:
        re = (XIRawEvent *) cookie->data;
        XQueryPointer(dpy, DefaultRootWindow(dpy),
                  &root_ret, &child_ret, &root_x, &root_y, &win_x, &win_y, &mask);
        printf ("raw %g,%g root %d,%d\n",
            re->raw_values[0], re->raw_values[1],
            root_x, root_y);
        break;
     
    XFreeEventData(dpy, cookie);
     
    return 0;
 

Hacks in xeyes Of course, one common mouse tracking application is xeyes, so I ve hacked up that code (on top of my present changes) here:

git clone git://people.freedesktop.org/~keithp/xeyes.git

If you're interested in security, brogramming, and throwing a few decades of UNIX best practices overboard... There's an app for that! The GIF they are using is oddly fitting, if for an entirely different reason than what they probably had in mind.