Slashdot Mirror
Ask Slashdot: How To Handle Unfixed Linux Accessibility Bugs?
dotancohen (1015143) writes "It is commonly said that open source software is preferable because if you need something changed, you can change it yourself. Well, I am not an Xorg developer and I cannot maintain a separate Xorg fork. Xorg version 1.13.1 introduced a bug which breaks the "Sticky Keys" accessibility option. Thus, handicapped users who rely on the feature cannot use Xorg-based systems with the affected versions and are stuck on older software versions. Though all pre-bug Linux distros are soon scheduled for retirement, there seems to be no fix in sight. Should disabled users stick with outdated, vulnerable, and unsupported Linux distros or should we move to OS-X / Windows?
The prospect of changing my OS, applications, and practices due to such an ostensibly small issue is frightening. Note that we are not discussing 'I don't like change' but rather 'this unintentional change is incompatible with my physical disability.' Thus this is not a case of every change breaks someone's workflow."
The prospect of changing my OS, applications, and practices due to such an ostensibly small issue is frightening. Note that we are not discussing 'I don't like change' but rather 'this unintentional change is incompatible with my physical disability.' Thus this is not a case of every change breaks someone's workflow."
From The Law of Success 2.0:
RMS: So if I'm using the free program and I make a change in it, which I know how to do, then I could publish my modified version and then you. Perhaps you're not a programmer; you would still be able to get the benefit of the change I make. Not only that, you could pay somebody to change the program for you, or you could join an organisation whose goal is to change a certain program in a certain way, and all the members would put in their money, and that's how they would hire a programmer to change it.
familiarity with being handicapped.
Somebody has already narrowed the problem down to specific patch:
Comment 7 Peter Hutterer 2014-01-16 05:43:43 UTC
bisected to this commit:
commit 11319a922575f1da1d3c5774728c0dee12bab069
Author: Peter Hutterer
Date: Thu Oct 11 16:03:33 2012 +1000
xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP
It would help if that number was a link to the git log.
I'll give you that this bug carries a tad more weight due to what I would think is a large impact, but the usual "no one is fixing this bug" answers apply:
- do it yourself (I get that this is often not an option, but including for completeness)
- convince someone else to do it
- pay someone to do it
- find some workaround
I support fixing this bug, Linux has far too many issues with this.
They might not have implemented that bug yet.
I think it's reasonable to believe that an Accessibility feature continue to work. And I think it's in the best interests of the Linux community for that to happen.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
So far 13 posts, and most of them are unhelpful drivel.
Way to prove Linux is superior.
Did he mention the system used to work as expected, and now is broken?
If I was a Linux advocate, I'd be ashamed of the community over stupid crap like this situation.
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
Some distros are supported for a long time, like CentOS, Ubuntu LTS and others (I dont' know them) and debian is half-decent with three years.
So it's easy to install a distro based on Ubuntu 12.04, you get support till 2017 so that buys you time till the bug is fixed! (or even some Wayland and graphics driver that work well enough, if the accessibility feature is implemented)
Debian wheezy uses Xorg 1.12.4 (I've just checked) and works till 2016, it has many derivates too (like Crunchbang)
I don't know too much about the rpm world, if not for CentOS, it is dated but has very long support. till 2020.
Basically what you want is to escalate this issue so that it gets more attention. As this affects people with disabilities I suspect you may get some results if you try to contact the Linux Foundation, who may then be able to twist a few arms or throw some resources at the problem as needed. You could, for example, point this very thread out to "pr@linuxfoundation.com" and let them know that this is a bit of a black eye against Linux.
It's unfortunately the worst kind of bug in a sense. A feature that affects only a small minority of users but affects them severely.
If some developer or company doesn't have a specific interest in that set of users it's really easy for the bug to get overlooked.
I wonder if this would be a good cause for a disabled rights group. Hire a dev or two to go around fixing/nagging open source projects in an effort to improve accessibility.
I stole this Sig
So far, we know that Peter caused the change, Peter knows that, and Peter knows how to put it back. Peter isn't sure that it's broken since it now follows the written spec. Ideally, we'd like Peter to fix it, but for that we need to convince Peter that the new behavior is wrong and it SHOULD be reverted. If he chooses to, it will take many seconds to revert the change.
What I'd do next is find the written documentation of the behavior in earlier versions, in Windows, and OSX. YOU said they all work the other way, but the spec says otherwise. So prove your case by linking to written documentation. When you post the links, mention "the principle of least surprise", a term meaning that users should not be surprised by the behavior of the software.
Also, right now ONE person on the planet has said they don't like the new behavior. If EVERYONE in a large group is having a problem with it, a few could post saying so. I'm sure there are forums and such related to accessibility, so ask around. Find out for sure, are other people reall having great difficulty with it? If so, will they post in the ticket?
Then mail Peter and request that he look at it. You could ask how much would be a fair contribution for his time spent looking into it. (Answer - about $20 - $50).
If Peter doesn't respond, email the project maintainer, mentioning that Peter seems to be unavailable and asking that the maintainer look at it.
If those two options fail, that single-line change is so small that any Linux programmer could compile a copy for you with it reverted. It would only take a minutes. Two years from now, if an important update comes out, someone could easily do the same with the new version. Obviously that's less desireable than getting the upstream source fixed, but it fixes YOUR problem.
OP seemed pretty clear that #2 isn't an option, and most disabled Americans' income is too limited for a case of beer or equivalent bribe.
I wouldn't consider it whining and moaning when somebody finds a bug that breaks disability accessibility to the point that they won't be able to use their OS without a struggle, politely posts to the bugtracker about it, waits for 3 months while it's ignored, then politely posts to Slashdot asking for suggestions on how to handle it. Instead, I'd say it's maturely pointing out a legit issue and requesting help -- not every mention of a problem qualifies as a whine/moan, especially such a critical problem.
Now mostly at Usenet:comp.misc & SoylentNews.org (it's made of people!)
That's a good point. Maybe someone will post it in the ticket.
It should be the job of whoever made the change that broke the system a year ago.
We defend Linus going postal on someone for breaking the user interface about music (or whatever that was last year), but are supposed to accept some douche breaking the ability of handicapped people to use their keyboard?? That's fucked up, with no pulling the punches.
I've used Linux various times over the years, and my daughter's laptop has Linux Mint on it. I'm not a programmer or Linux guru, and have never claimed I was. I also don't particularly like how some in the the disabled community have subverted the Americans With Disabilities Act. But I will call bullshit on this type of bullshit every time.
Thanks for the response.
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
Read the bug report. The accessibility feature works. The submitter (who also happens to be the bug reporter) found a fairly minor subfeature (the ability for sticky key modifiers to act as lock keys) has been broken recently. I say fairly minor, because the only key this might be critical for in certain use cases is the Shift key, where a separate Caps Lock is already available. Exaggerating the issue by claiming it makes accessibility on Xorg unusable and bitching on slashdot because its been a whole 11 weeks since he found the problem and noone has released a fixed version yet is just grandstanding.
Shift and Caps Lock don't necessarily have the same output!
On my keyboard, shift does 1234567890+ on the top row and Caps Lock does &É"'(-È_ÇÀ)=
The bug was reported in December 2013, and expecting a three month turnaround from a free project for bug fixes is a bit much. There are plenty of older distros that are still supported and work, so the sky isn't falling. And, believe me, recent Linux distros break plenty of people's user interfaces in plenty of ways that are just as inconvenient as not having sticky key work may be to you. In addition, if you really care, you can write a user-mode program to give you the same functionality.
So, my suggestion is: just switch to Windows or OS/X. I'm sure those commercial systems will give you bug fixes with three months turnaround. You deserve the kind of service and support that Microsoft and Apple give you!
Read the bug report. The accessibility feature works. The submitter (who also happens to be the bug reporter) found a fairly minor subfeature (the ability for sticky key modifiers to act as lock keys) has been broken recently. I say fairly minor, because the only key this might be critical for in certain use cases is the Shift key, where a separate Caps Lock is already available.
The bug is asking for the wrong fix
Different modifiers have different combinatorial effects. Caps Lock is not necessarily Caps Lock, in other words. I know that most Linux people hate them because they are cheap, and you have to do a "disable secure boot" dance to install Linux on them, but ChromeBooks, in particular, lack a Caps Lock key. Caps Lock is achieved by hitting both shift keys simultaneously.
If that isn't convincing enough, consider Alt-Gr vs. Right-Alt behaviour on international keyboards that report a USB HID country code of 00h.
While I was working on ChromeOS at Google, there were a number of obvious usability issues for the OS, but the majority of them stemmed from the need to upstream support into Linux, and the difficulty of doing this without involving an Alan Cox, Ingo Molnar, or similar personage when you were dealing with things which crossed area boundaries. Input is one of these areas, and it was rather difficult and roundabout to get support for non-adjusted raw system time stamps in evdev inputs, even as a non-default option.
Exaggerating the issue by claiming it makes accessibility on Xorg unusable and bitching on slashdot because its been a whole 11 weeks since he found the problem and noone has released a fixed version yet is just grandstanding.
I agree the issue is exaggerated, but mostly because I disagree about where in the input stack usability issues should be addressed. The usability belongs in the input stack, as does the internationalization, below the point at which events are reported to the console, or to X (or Wayland or whatever display server is handling the apps and forwarding the input events).
It's pretty easy to see where this breaks down by enabling "programmer mode" (meaning: disabling "secure boot mode") on a ChromeBook, and enabling root or other console logins. It's easy to see the shift-shift (or Caps Lock, if you plug in a standard USB keyboard) and internationalized input don't work the same on the console as they do in the graphical environment.
In general, the input stack in Linux has a *lot* of problems. A fun experiment to try is plugging in 3 or 4 USB keyboards, and playing with the Caps Lock; the light goes on or off on whatever keyboard you're playing with it on, but the actual Caps Lock state depends on whether you've hit the Caps Lock key on an even or odd number of keyboards, and the keyboard Caps Lock lights very quickly become desynchronized from the actual Caps Lock state (i.e. turning Caps Lock on on keyboard A lights the light on A, and hitting it on B turns it on on B, rather than off on A, even though the state is that Caps Lock is no longer in effect).
Similar issues occur when using sticky modifiers for usability, and when moving between virtual consoles with various modifier/Caps Lock/etc. states in effect.
I understand the idea that you may wish to explicitly allocate resources in a multihead environment, but the input stack really doesn't do that very well, either - these modifiers should happen in the input stream above a stream join as a resource allocate by a virtual console or display server, and not in the display server or the underlying driver.
Windows doesn't support multihead well (at all, for multiple sessions, without something like Citrix intermediating the process), but it also doesn't screw up on where it put the internationalization translation tables and the dispatch routines and the usability.
PS: In case you care, AFAIK, there are zero vendors who put the correct internationalization keyboard code type in the USB
A "shame the developer" post to Slashdot is not the same thing as pinging the developer directly, and makes this really undesirable to fix, as it implies that similar pressure would work on the same developer in the future. If I'm a volunteer, I really don't appreciate you making demands on my time with the threat of publicly thrown tomatoes to back up your demands should I not meet them in a fashion you consider timely.
It's also pretty ass to insist on a release schedule for a change (see previous post: what the OP wants is technically not a "fix", since it perpetuates inappropriate software layering) to software which is not normally released on a schedule, and which does not have specific changes preannounced until the code is actually done, since they may or may not make a particular release.
If you want that, with respect, you should consider running only Canonical releases, and buying a support contract from Canonical, or if you don't like that, make friends with someone else who has already bought one.
Agreed. It's even worse when you realize just how many accessibility features exist in Windows - they've got almost everything, and you can expect them to work given there's high visibility of the operating system compared to most Linux distros. But of course people prefer to joke instead of accept the fact that Linux distros simply don't have the same level of support for accessibility features as seen in the proprietary systems, and that continual joking is why I don't bother with Linux for my own system anymore.
Small tweaks are doable, but even then you will get a lot of hassle. You will spend a good amount reading source code, setting up the build environment and after that maintaining your own fork if the upstream didn't accept your change.
For anything larger, you will also need to acquire a large amount of understanding how the particular system works before you can make the proper change. For example, good luck fixing a graphics driver bug (even if it looks like a simple glitch) if you do not know how graphics drivers work. Getting familiar with the bigger picture will take weeks or months.
Now, that does not mean that open source is not useful. The people familiar with graphics drivers (for example, Freedesktop and Mesa guys) can collaborate using open source. But they are experts in their field. If you are outside of this specific expertise, your best bet is usually writing accurate bug reports. You cannot go there and fix everything that is broken just because you have the source.
Try this sometimes. When you find a bug in open source software, take the responsibility of fixing it properly and sending the patch. Doooo it, walk the walk. The point is that you will notice how much work it all involves.
put this patch in /etc/portage/patches/x11-base/xorg-server/
stickykeysfix.patch
It simply reverts the problem causing commit and now sticky keys are released after a mouseclick on my system. I don't know if this introduces other bugs though.