Ask Slashdot: How To Handle Unfixed Linux Accessibility Bugs? 266
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."
RMS mentions a comparable situation (Score:4, Interesting)
From The Law of Success 2.0 [gnu.org]:
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.
Re: (Score:3, Informative)
There's one major problem there: most disabled people in the US are living on Supplemental Security Income of $600-850/month, and have no other source of money. Even a group of them are unlikely to be able to pool enough to hire somebody to fix a bug in something like Xorg.
Re:RMS mentions a comparable situation (Score:5, Funny)
The open source community is pretty cool. Simply getting together in the right forum would likely get the right people interested in helping you. Hell I'd start with posting to Slashdot... hey... WAIT A MINUTE WE'VE BEEN HAD!!!
Re: (Score:3)
It's like charities don't exist. It's like kickstarter never happened. I feel sorry for the dystopian timeline you left when you joined ours.
Re:RMS mentions a comparable situation (Score:5, Insightful)
The sad part is that it is a known bug, that got introduced breaking a perfectly working feature, and is still not fixed. It is not a new feature they're asking for, just to retain something that was always there.
This is programmers not doing their job - and it being FOSS that is distributed for free is irrelevant as it's more than a hobby-level tool we're talking about. It's production-level software, and essential to the operation of a large number of computer systems.
Re: (Score:3)
Re: (Score:3)
There's one major problem there: most disabled people in the US are living on Supplemental Security Income of $600-850/month, and have no other source of money. Even a group of them are unlikely to be able to pool enough to hire somebody to fix a bug in something like Xorg.
This is also potentially a huge benefit. I really enjoy working to make GNU/Linux more accessible. I'd do it full time if I could, but I cant afford to. I don't have the time, and companies wont pay me to do it.
People with disabilities, as you suggest, often have no job and little money. They often have lot's of free time that could be spend improving FOSS accessibility. A primary vision of the Accessible Computing Foundation is creating a world where people with disabilities help themselves by creatin
Re:RMS mentions a comparable situation (Score:5, Funny)
Re: (Score:2)
Use the old outdated software.
Of course this shouldn't even be an issue. You would think accesibility features would be a priority within the community or some segment of it.
Re:RMS mentions a comparable situation (Score:5, Interesting)
Kudos to RMS for believing accessibility is a human right, and taking action personally to promote accessibility in Linux. Fixing accessibility in Linux is a mess, but if we can get enough people involved, it's doable. This is the mission of multiple efforts, and the one I'm involved in is the ACF (Accessible Computing Foundation). The free software movement, and the goal of people with disabilities taking control of their computing environments are well aligned. GNU/Linux provides a platform where at least in theory any and all accessibility issues can be corrected, unlike Windows and Mac OS X.
Unfortunately there are considerable obstacles to "fixing" accessibility in Linux. I believe they can be overcome if enough people come together to make it happen, but there are huge challenges. There are also people who devote a lot of their lives to improving the situation, often for free or very low financial incentive. I spearheaded the 3.0 release of Vinux, which is Linux for the Vision Impaired. I fixed a dozen or so accessibility bugs, but the right fix in many cases would involve major changes to GNU/Linux. I'll list a few.
The accessibility API in GNU/Linux, atk/at-spi, should have shared more functionality with Windows. For typical corporate and FOSS anti-Windows reasons, the accessibility stack was built intentionally in a Windows incompatible way. The result is that accessibility in Firefox and many other major applications never works as well in Linux as it does in Windows. It simply is not reasonable to make every software vendor do all their accessibility coding N times for N operating systems. There is even an effort called Iaccessible2, which is basically a FOSS accessibility stack for Windows, which the creators seemed to hope could also work for Linux. The code was even donated to the Linux Foundation. However, there was never any money or motivation in FOSS land to actually port the software to Linux, SFAIK. Building a single accessibility API that works in Windows, GNU/Linux, Android, and Mac OS X would go a long way towards fixing accessibility in all of those places, but especially in GNU/Linux, since it is usually the OS vendors put the least effort into. As it stands, few GNU/Linux distros are able to keep FireFox and LibreOffice accessibility working.
Then there's the problem of Linux being a multi-headed Hydra monster with no one in charge. At Microsoft, Bill Gates took a personal interest in accessibility, and that's all it took for the entire company to take accessibility seriously. In GNU/Linux land, RMS also takes a strong personal interest in accessibility, but it's not like most of the devs work for the guy. RMS can make his case, but when your boss is asking for prettier GTK+ widgets in Gnome 3 and you're late delivering, accessibility fixes fall by the wayside. When we are lucky enough for a patch to be developed, many times the GNU/Linux authors refuse to include them, because the "fix" is not perfect. For example, I added accessible descriptions to pixmaps in GTK+, which enabled blind users to hear 'star' for a star icon in a table containing pixmaps. The devs could not decide if pixmap was the right place for this accessible description, enabling them to justify doing nothing, and the continued lack of support for accessible icons was the result. It saved them a few hours of work in testing, which was their real priority. Multiply this asinine situation 100X, and you begin to understand why making Linux accessible is hard. GNU/Linux land seems to take pride in making it hard to fix accessibility, because we make it almost impossible to override any given stupid author's decision not to support accessibility. I should be able to patch GTK+, and have that patch automatically distributed to every user of every distro who believes my accessibility patches are something they want. Instead, we've built a system where patches have to be accepted by the authors, and then distributed slowly over years to the stable distros. Stupid, stupid, stupid...
go Windows (Score:4, Funny)
Re: (Score:3, Informative)
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
It's been bisected and confirmed (Score:5, Insightful)
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.
Re: (Score:2)
Could you create a downstream diff at the distribution level to resolve the bug?
fix for Gentoo Linux (Score:5, Informative)
stickykeysfix.patch [pastebin.com]
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.
Re:It's been bisected and confirmed (Score:5, Informative)
Goddamn that was painful, but I found the actual patch:
http://cgit.freedesktop.org/xo... [freedesktop.org]
I would say it is rather shocking that this Peter Hutterer actually did about 90% of the work, then posted something that is not a clue as to how to see the answer.
And that the original poster (who I assume made this Slashdot story) did not post any followup for 3 months, probably leading Peter to forget all about fixing this.
Re: (Score:3)
I'll bet this is going to be patched in the git repositor within a half hour.
But I'm not sure if posting Slashdot stories is the best way to get a bug fixed. But if it is the only one that works, might as well do it.
I still feel the original poster should have put *something* on that bug report in all the time since January 16th!
Re:It's been bisected and confirmed (Score:5, Insightful)
I'll bet this is going to be patched in the git repositor within a half hour.
Reverting would be easy - I'm don't know enough about X to understand if the IsMaster(mouse) test can easily be augmented to not break StickyKeys, but fixing a null pointer dereference is something that needs to be done.
But for just the users' use case (and people will hate this) - this is where paying somebody to deal with the problem for you comes in.
A decent hacker would have done the work you did in the first hour, created a distro patch in the second, and put up a repo with the new packages in the third. Throw in an hour for testing.
It seems likely that there are enough people affected by this that if they all threw in a dollar it would have been done by the next day. What we might have here is a community coordination problem, not just a software bug.
Re: (Score:3)
fixing a null pointer dereference is something that needs to be done.
FFS... that's the issue?
Screw hiring developers, let's start a kickstarter and hire someone to break the kneecaps of whoever committed the broken code.
Re: (Score:2, Interesting)
It seems likely that there are enough people affected by this that if they all threw in a dollar it would have been done by the next day. What we might have here is a community coordination problem, not just a software bug.
Or, you know, just giving a head's up to the dev who was already bisecting the bug and what not. That the bug was left for months without follow-up from "affects me too on $OS $VERSION" is the problem. Instead of being so hyperbolic and moronic as to resorting to paying people and bitiching about it on a tech news site and saying, OH, SHOULD I JUST SWITCH TO $PROPRIETARY SOFTWARE like some kind of moron or shill, the affected party could have opened a new (duplicate) bug, but seeing as they already knew a
Re: (Score:2, Informative)
Spitzak your "not post any follow up for 3 months" statement seems to easy to disprove.
https://bugs.freedesktop.org/show_bug.cgi?id=73155
Dotan Cohen 2013-12-30 14:46:05 UTC - Original post
Dotan Cohen 2013-12-30 18:46:10 UTC - response same day
Dotan Cohen 2014-01-10 13:25:23 UTC - initial response to Peter Hutterer
Dotan Cohen 2014-02-14 10:20:39 UTC - second response to Peter Hutterer (includes a thank you)
Dotan Cohen 2014-03-21 12:35:54 UTC - inquiry on possible schedule to fix
Slashdot post
Dotan Cohen 2014
A "shame the developer" post to Slashdot... (Score:3)
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: w
Re: (Score:2)
If that patch didn't exist, I'd recommend finding the mailing list or forum, then asking them. Else, check the package maintainer for your distribution, and email them directly.
Re: (Score:2, Insightful)
Mmm (Score:3)
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
Re:Mmm (Score:4, Insightful)
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 think OP is trying to do the second one with this article. Perhaps someone will read this and be embarrassed enough to fix it.
Re: (Score:2)
I think OP is trying to do the second one [...convince someone else to do it...] with this article. Perhaps someone will read this and be embarrassed enough to fix it.
Or perhaps it will backfire to discourage other people from posting future embarrassing articles every time someone has a problem where they consider a change a bug, and want the behaviour reverted?
Re:Mmm (Score:4, Interesting)
Sometimes it isn't an option because your fix gets rejected (or left to idle in an obscure bug report)
For example, one build utility had a bug where it checked for the presense of a compiler, but not if it was functional. The fix was rejected because the build utility doesn't check path - despite the fact that it does so for a different compiler. (Explicitly defining which compiler to use defeats the purpose of using said tool in the first place - I'd just use Makefile instead.)
Did you know it took 10+ years for Mozilla to fix the alert() denial loop [mozilla.org]? That bug is older than Mozilla itself, and the most obvious fix of "checkbox to stop further dialogs" was dismissed as a hack (compared to the destructive hack of force-killing Mozilla.)
Re: (Score:2)
Well, sometimes even if you get the patch accepted it STILL doesn't fix the issue.
For example, I once submitted a patch and had it accepted to a project, but the maintainer had died before releasing a new build. This was severely inconsiderate because I really needed this bug to be fixed. What other extreme "+1 Interesting" edge cases can you think of for why all of the normal options just couldn't work? What possible hope can we have of a fix when a cosmic ray could change a bit of the release binary an
Re: (Score:3)
Did you know it took 10+ years for Mozilla to fix the alert() denial loop [mozilla.org]? That bug is older than Mozilla itself, and the most obvious fix of "checkbox to stop further dialogs" was dismissed as a hack (compared to the destructive hack of force-killing Mozilla.)
Yeah, and it should be reverted to the prior behavior because it doesn't fix the issue. If you're giving someone an infinite alert loop, then your code is bad or malicious.
Whether it is bad or malicious this "fix" doesn't fix the issue at all. The very same "denial of service" is easily produced by wrapping an infinite loop in a short window.setInterval(...);. Then instead of an alert() popup you get a never-ending stream of "would you like to stop the script?" dialogs. So, if it's a pop-up dialog deni
Re: (Score:3)
Prior behavior was with Windows 95/98 and really old versions of Netscape, where the browser blindly loaded an image from c:\con\con because that's the file found in the img tag. Unlike the BSoD, you needed a 110 reset.
And no, you should never revert to a revision that provides worse control over malicious scripts.
The script-stopping dialog woul
Re: (Score:2)
As someone who is Handicapped (Score:3)
I support fixing this bug, Linux has far too many issues with this.
Re:As someone who is Handicapped (Score:4, Insightful)
I agree. Last I heard, we *wanted* people to use Linux on the desktop.
Re:As someone who is Handicapped (Score:5, Funny)
I agree. Last I heard, we *wanted* people to use Linux on the desktop.
That's just a rumor that the Gnome guys would take issue with.
Switch to wayland (Score:4, Funny)
They might not have implemented that bug yet.
What the hell is wrong with some people? (Score:2, Insightful)
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.
Re:What the hell is wrong with some people? (Score:4, Insightful)
I am incapable of fixing it. (and I have a Bachelors degree of IT/CS) and I'll assume the person posting can't fix it. An upstanding member of the community NEEDS to fix this. I am ashamed over this.
Re: (Score:2)
Hi Zombie. Your posts were in the group that wasn't "unhelpful drivel". Sorry if you thought I was attacking you.
My share of outrage grew as I was reading the initial responses, quoting Stallman and saying 'go fix it yourself'. I refreshed the screen before posting, to get an accurate count, and saw your responses then.
I thought about specifying the ones that were or weren't drivel, but decided it would dilute the message, and after 30 more minutes, no one would know which were in those initial groups.
Anyho
Re: (Score:2)
The problem illustrates technology egos gone mad.
Of course they know 99% of even technical people simply cannot fix software of this complexity. They are waiting for everyone else to point out how inadequate ordinary people or even ordinary software developers are compared to masters such as themselves, because they would rather listen to that than follow through with whatever commitment they made.
Re: (Score:2, Informative)
No kidding, eh?
Not the only instance. Here's one from ages ago, identified initially as an accessibility issue:
https://bugreports.qt-project.org/browse/QTBUG-24304
even prodvided test case to demonstrate it. Finally gets a response ~ 1 1/2 *years* later:
"... Believe it or not, we have other priorities (this is actually not the only open bug!) and some of them even support our jobs so that we can continue working on Qt. ..."
This kind of lack of interest in accessibility is why we don't use any Linux on the
Patch link posted before your post (Score:2)
http://linux.slashdot.org/comm... [slashdot.org]
Re: (Score:2)
Even that poster, spitzak, calls the process he went through "painful", and the lack of completion "shocking". I glad the patch is available, and am happy that the people who really need it will be able to get it after upgrading from their unsupported versions of software they been forced to use because of the issue.
By the way, he posted one minute before I did. So while I was typing and previewing my post. And after I refreshed my screen before typing my post, to be more accurate. Don't make it seem like I
Re: (Score:2)
Typical partisan hack commie; your ticket would bring only serfdom.
I, and any true American lover of liberty, demand a Libertarian president and Green Party vice president! ;-)
Re: (Score:2)
Typical partisan hack commie; your ticket would bring only serfdom.
Huh? What ticket? I'm talking about Linux, not going to the movies.
I, and any true American lover of liberty, demand a Libertarian president and Green Party vice president! ;-)
OMG!! roflmao
You got me good. :^)
But in the end, you are completely wrong and are the whole reason we can't have nice things. :^P
Re: (Score:3)
Re: (Score:2)
That aspect did occur to me. But the few who seemed genuinely sincere in support of Linux were not any more helpful than the ones who were simply trolling. Only zombie and roc were supportive in a meaningful way. And when I initally saw the article, there were only 8 messages. It went up to 13 when I refreshed the display for more accuracy. Spitzak finally linked to the patch and showed that it was being committed to git, but his initial post, which I saw as I was typing my own post, only showed that there
Re: (Score:2)
So far 13 posts, and most of them are unhelpful drivel. Way to prove Linux is superior.
This thread shows a lot of what is wrong in the Linux community.
.
A significant bug appears, and little is posted besides drivel.
Way to go Linux Community.
Just fix the damn bug.
Re:You fix it (Score:4, Insightful)
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.
Re:What the hell is wrong with some people? (Score:4, Insightful)
So far 13 posts, and most of them are unhelpful drivel.
The worst being the posts that suggest the disabled should cough up the money to pay for a fix or fix the problem themselves. It would be rough justice to put these posters on an SSI budget and see how well they fare.
Re: (Score:2)
Exactly.
It's not like we are outraged that something in Linux doesn't work quite right. Or that something has never worked quite right. And it certainly isn't something that a 'special interest group' wants added. It was a previously-working feature that was broken for some reason. The /.er that wrote the original story was very candid and reserved, considering the personal nature of what he was addressing.
And the response were "well, that's free software for you", "fix it yourself" "the rms says blahblahbl
Re: (Score:2)
If it makes you feel any better, my first reaction on seeing this was "Hmm, let me read the comments and see if anyone has a fix or workaround, and if not, hell, I'm sitting around in hospital bored out of my mind. I'm not familiar with the Xorg code tree, but this would be a great thing to spend a weekend to get my feet wet." I'd like to think that there were at least a few of us out here in the same place (well, maybe not the hospital part ;-)), leaving chuckleheads to post before the people who rolled up
Re: (Score:2)
You make a good point or two. But if you think a little talk is going to make me feel better, ... just kidding. It helps quell the rage. ;^)
Hope your hospital stay goes well.
Re: (Score:3)
The easy and classic way of prioritizing bugs is to count the number of people complaining.
You can throw a severity field in there, but it's always subjective and 10,000 users complaining about a "medium severity" bug is probably going to rise above 2 or 3 complaining about a "ultra high my life is over total showstopper" bug.
This model mostly works but of course falls apart when you've got the high impact to low user count bugs.
Re: (Score:2)
Still better than the "we pretend to care about our customers, but really care about protecting our image from damage by legitimate complaints" non-committal corporate newspeak that most closed vendors respond with.
Re: (Score:3)
Are you sure it was working as expected before? The current behaviour seems quite convenient, and quite possibly could have been the original intention of the feature, especially since the fix that has changed the behaviour seems to be the correct fix for other problems involving distinction between mouse and keyboard events. A lot of fuss is being made about the fact that the bug reporter needs to press Ctrl a second time to cancel his
Re: (Score:2)
How does your post help the submitter? Your post and now mine aren't any more helpful than those you call unhelpful drivel.
I use both Windows and Debian GNU/Linux. Both work fine for me. There are nice and not-so-nice people in both Windows and Linux communities. The niceness of the community doesn't have anything to do with technical superiority or inferiority of the operating systems (or kernels if you will).
Re: (Score:2)
Most posts on Slashdot are unhelpful drivel, although some are golden.
How do comments made on slashdot relate to Linux?
Did he mention the system used to work as expected, and now is broken?
I read your comment why wouldn't I have read the summary? but yes it is at the top of the page if you use your page up button you can check for yourself. do you have a UI that allows you to do that? You might consider my reply insulting but look at what you wrote.
If I was a Linux advocate, I'd be ashamed of the community over stupid crap like this situation.
which community? which situation? That a Slashdot story has a lot of crappy comments? That you post flamebait and it gets modded
Use older version.. (Score:4, Informative)
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.
Re: (Score:2)
There are some solutions to that problem. CentOS backports features into older kernels, Ubuntu has the LTS enablement stack, which is included in installation media as Ubuntu 12.04.2, 12.04.3, 12.04.4 etc. In this case though, the Xorg server is updated which is what we wanted to avoid.
Older gens of hardware parts can still be bought new, like a Sandy Bridge Pentium or Celeron, or a 760G motherboard and Sempron 145, or an AMD E-350 Pentium. Graphics cards like Geforce 210 still sold. Tech from 2009 to 2011
Re:Use older version.. (Score:4, Insightful)
Contact the Linux Foundation (Score:5, Informative)
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 [linuxfoundation.org], 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.
Re: (Score:2)
This is a very productive post. Thank you for an intelligent answer that will help this person in the future. Teach a man to fish and you feed him forever.
Re:Contact the Linux Foundation (Score:5, Insightful)
and let them know that this is a bit of a black eye against Linux.
Or, you could recognize TFA as the hit-piece it is: Points to the Bug, knows what a bug tracker is, doesn't use the bug tracker to fix the issue: Open a new duplicate bug to get it re-triaged and noticed by more than just the bug assignee. Escalate the issue to other devs. It's not like the devs are saying: NO WE DO NOT GIVE A FLYING FUCK ABOUT DISABLED PEOPLE GO USE MICROSOFT OR APPLE, ANYTHING BUT A FREE AND OPEN SOURCE OPERATING SYSTEM.
This is a tempest in a teapot with sizable negative PR spin. I do not negotiate with terrorists. I do not speak for everyone, but to the users who jump to shaming tactics instead of resolution options: Fuck you, I don't give a flying fuck about your persecution complex. I would rather not deal with such disgusting shit-stirrers.
For future reference, Submitter, if you're reading this: How to ask a question the smart way. [catb.org] -- Everything here also pertains to bugs or questions like "Why isn't this fixed yet?". The answer? You reap what you sew.
Re:Contact the Linux Foundation (Score:5, Insightful)
So you report a bug the way you're supposed to, it barely gets attention, and you think re-reporting it the same way will suddenly do the trick?
Well repeated often enough it may - but it also shows the failure of devs to use their own bug tracking system.
A few options (Score:5, Insightful)
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.
Re: (Score:2)
was a fix to make follow the specification (Score:2)
The change was to make it follow the written specification, a bug fix. The reporter is saying that the bug fix wasn't, because he figures the old behavior is better.
I have no idea which way it should work, but the ticket has the submitter expressing one opinion and Peter expressing another opinion. Not long ago, I submitted a fix for a bug in an open source project. It was obviously bug, the documentation said it worked one way, the code did the opposite. I fixed it to work according to the documentatio
Re: (Score:2)
Re: (Score:2)
The spec in question - http://www.x.org/docs/XKB/XKBp... [x.org] as Peter references in the bug comments - discusses StickyKeys (4.4 on page 9) and strongly implies modifiers only unlatch on key presses; mouse buttons are not mentioned. His change made the code match this reading of the spec. I have a hard time believing that's what the spec writers intended, but if so then KDE's lock checkbox really isn't supposed to do anything.
Re: (Score:2)
Re: (Score:2)
Re:A few options (Score:5, Insightful)
I do know that even as a non-disabled user, the behavior Peter describes as "per spec" (that is, mouse buttons are not keys for the purposes of releasing the sticky keys) is counter-intuitive since the modifier keys interact with mouse buttons the same way they do with non-modifier keys (ie. Control modifies selection with mouse clicks the same way it modifies selection with the keyboard). Given that normal interaction with both non-modifier keys and mouse buttons, I'd expect instructions about how modifier keys behave to also apply analogously when both non-modifier keys and mouse buttons (but not mouse movements) are involved. Either that or I would expect modifier keys to not interact with mouse clicks the same way they do with regular keys.
good point. Should be in the ticket (Score:3)
That's a good point. Maybe someone will post it in the ticket.
Re: (Score:2)
I just tested and OS X treats the clicks and key presses the same way when sticky keys is enabled. Hit the modifier, the next click or key press is modified. Hit the modifier twice and all clicks and key presses and modified until you hit the modifier again to unlock.
Seems very much the logical way to do it.
How To Handle Unfixed Linux Bug (Score:2)
XKB Specification is the problem!? (Score:2)
Reading the bug report commentary, it appears there's an error in the specification: http://www.x.org/docs/XKB/XKBp... [x.org] that Peter Hutterer propagated into the code. The specification should be fixed as well as the code. Peter's comments about the change also discuss a null-pointer dereference problem - I'm not clear how that is related to the change - and therefore whether reverting the change is the complete solution.
The specification appears to be dated 1997-12-15, so all this is blowback from 16-year-old
yes, better switch to something else (Score:3)
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!
Use windows (Score:2)
Just use windows. It doesn't really work any better but at least they don't break core functionality a few times a year and then take months to fix it...
Ok maybe I'm exaggerating and this is only an Ubuntu problem; it's been years since I've been annoying-bug-free for more than 3 months with...
Re:What did you expect? (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
Or, alternatively, hire a lawyer, and sue x.org for violating the ADA [wikipedia.org]. That is the American way.
Re: (Score:2)
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
Or, alternatively, hire a lawyer, and sue x.org for violating the ADA [wikipedia.org]. That is the American way.
It sounds like you mostly want to take a shot at the ADA but looking at the link I don't see any mention of software except for the two instances where courts have ruled that websites aren't covered. Is there any precedent for a software project being sued on the basis of the ADA?
Re: (Score:2)
I don't remember if it was softwsre itself or the government entity using it, but there have been some lawsuits that i can remember hearing about concerning accesability features. It had to do with government using software.
Re:What did you expect? (Score:5, Informative)
Re: (Score:3)
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 is asking for the wrong fix (Score:5, Informative)
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
Re: (Score:3)
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.
Actually it does, frighteningly well.
http://en.wikipedia.org/wiki/W... [wikipedia.org]
You are quite correct however, this is a painfully ridiculous situation with the input handlers in Linux.
Multiseat and multihead seems so perfectly fitting as something Linux should be doing, but it fails miserably from the start due to the input handlers.
The real kick in the teeth bit about the Windows solution? You have to pay a full OS license for each seat/head configured!
If your goals are anything more complex than "I just wanted to
Re: (Score:2)
I suspect that we are hearing a little bit of frustration. And surely this is a low hanging fruit -- a lot of positive karma could be had for what sounds like a reasonable amount of programming.
Re: (Score:2, Insightful)
I'll repeat my response to someone else above:
Most disabled people in the US are living on Supplemental Security Income of $600-850/month, and have no other source of money. Even a group of them are unlikely to be able to pool enough to hire somebody to fix a bug in something like Xorg.
Re: (Score:2)
X is not Windows. While I do sometimes get the annoying popup on Windows systems, I have never had that issue on my KDE desktop. Even on Windows there's a configuration option in the Control Panel to disable it. So no, it is not a "burden" to anyone, really. Unless you're using Windows (which isn't what this topic was about anyway), and are too lazy to spend 30 seconds on Google figuring out how to disable it.
I'll grant you that maybe Windows should have the feature disabled by default...
Re: (Score:2)
It only buggered me when playing Prince of Persia (the 1989 game) on Windows XP with VDMSound. So, not very much at all.
Re: (Score:2)
I hate that stupid Windows Sticky Keys popup too. Then again I think this is more a problem of OS configuration than anything else.
Re: (Score:2)
Except this is totally wrong, because the burden on other users consists of "turn it off if you don't want it", which you only have to do once ever, while the people who need the accommodation are gonna have serious problems without it.
Disability accommodation is a good thing for society. Yes, it can have some costs for other people, but they are small costs and in general we can easily pay them.
Re: (Score:3)
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 poin
Re: (Score:2)
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.
The same can be said for their support groups.
The question then becomes "Why have these problems been solved for years - a decade or more - in commercial/proprietary operating systems from corporate giants like Microsoft and Apple, who should - in theory - have even less interest in investing rime and money in providing services for the disabled?
No, contributing is contributing. Using is selfish (Score:2)
This user DID contribute by filing a reasonably good bug report. As to any other users who may or may not think the change is good or bad, if they didn't exist, we wouldn't get their feedback, but we also WOULDN'T CARE what non-existent people think. Therefore, the "contribution" you think they make is null. They express an opinion that matters to them, but if they didn't use the software nothing would be lost.
Authoring software helps other, so that's a contribution to the community.
Authoring documentati
Re: (Score:2)
Using the software helps noone but yourself - it's inherently selfish.
That's an overly-simplistic analysis. Using software has network effects. ('Network' in the social sense, not the move bits from point A to point B sense.)
Simply being a user that uses Libre Office and trades documents with others in that format grows the network of Libre Office users. That is a beneficial network effect. Simply being a user of X-Windows creates a larger pool of X-Windows users and therefore more potential seats for any random X-Windows application, which is a beneficial network effect f
except that 0 * x = 0. it's good because it's good (Score:2)
In summary, you said:
More users is good because it results in more users.
If adding one non-contributing user has no benefit other than attracting another, the total benefit is two users multiplied by zero contribution = zero.
Re:Fix it yourself you (Score:5, Insightful)
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.