Software all the way up the input stack seems to be a bit confused about a few things, or there is a lack of understanding that:
- graphics tablet digitisers generally are not and don't include touch digitisers
- tablets are not touch screens
- a stylus (tip) isn't a button
- a stylus can have buttons
By convention, stylus tip interactions are "tools", which seems to be what Linux' BTN_TOOL_* codes are meant to mean. A button on a stylus should never be (directly) translated to a tool -- like how the ~5th button on a mouse is `BTN_EXTRA`, not `BTN_MOUSE`. In this particular case it looks like the thinking is: the device has 2 event codes (which we know as the stylus tip and the barrel button) and it's a stylus^wdigitiser, so map device[0] to `BTN_DIGI` and device[1] to `BTN_DIGI + 1`.
editendum: the thing about the BTN_EXTRA doesn't really map... The "digitiser" event codes are being treated in the same way as mouse event codes (device[i] => event[CLASS + i]). The issue is really that the barrel buttons have no (dedicated) event codes.
The XP-Pen hardware reports HID "Eraser" usage (some digitizers with accompanying HID "Invert" usage, others without) for the top button. Linux' generic driver does here nothing more than forwarding the corresponding events from hardware to the userspace.
The missing Invert usage caused Linux to report Eraser as regular tip touch to the userspace, which was not intended but caused by an oversight in the kernel code. This, together with a bunch of hacks (Digimend and X11 tweaks), allowed OP to map that button to a right click.
Now, with the kernel logic fixed, these hacks do not work anymore. This is a case of xkcd://1172. The userspace solution is to remap BTN_TOOL_RUBBER to a right click for the weird stylus instead.
Yes, barrel switches should ideally be reported as "Barrel Switch" and "Secondary Barrel Switch". I have a Huion tablet[-1] that reports the second barrel switch as Eraser. The secondary barrel switch was not in HID originally[0], and I guess some devices were designed to follow an earlier spec -- that, or avoiding Wacom patents.
[-1] I don't remember if it's also a uclogic controller?
I recently started a remote scientist job, and its kind of insane that I am the only person among dozens who use a tablet+stylus during meetings. People have such poor discussions, because unlike a irl meeting where multiple people will write stuff on a whiteboard, here people are just communicating verbally (read vaguely) or painfully scratching unintelligible diagrams/equations with their mouse.
I think every remote job that sends employees a laptop should also be sending them a wacom tablet.
People look at me like I'm crazy because I use a wacom tablet as mouse.
I'm using a "cheap" one (I think it was like 80 EUR), and it's mind blowing how convenient it is despite its small size. Now trying to use a physical whiteboard for brainstorming, feels the same way as trying to use pen and paper for programming: technically doable, but I curse internally because the inconvenience.
Just being able to select stuff and move it around, or undo with a quick Ctrl+Z, or rotate things, makes all the difference.
Sure, I love using a paper notebook for my notes, and the feel of writing with a pencil on paper is really nice; and I would use it for drawing quick stuff if I don't have anything else at hand. But if I think I'm going to be erasing a lot, or that I will be doing the kind of stuff that is usually done with a whiteboard, a drawing tablet is (to me) a vastly superior option.
Not really a solution as much as an alternative form of attack: Tools like graphviz where I can type certain limited types of diagrams into a text editor and xdot well instantly display the render.
There are also some online ones, although I'm not sure how well they work in a multi-editor situation.
Might not be flexible enough for a really open brainstorming, but enough for stuff like figuring out domain concepts.
PlantUML - quick and simple text representation of diagrams, really easy to iterate on and see changes reflected live.
reveal.js - Quick and simple slide creation, I can reorder slides with ease, tweak wording, don't waste time faffing about with fonts, text box sizing etc. All reflected live in a browser.
Yup. Writing on paper with a nice fountain pen or pencil is primal love. So satisfying. But digital tablets are so much superior for that messy kind of work, you just have to use them.
I once got an bigger "upgrade" for my small wacom tablet, but it only collected dust. It used too much space on the desk to always keep it ready, and the larger active area meant too much travel distance when using the pen as a mouse.
And concerning Wacom, they were the first to have someone working on Linux drivers, and the only one for a long time, back when tablets were new. Not sure how it is today.
> And concerning Wacom, they were the first to have someone working on Linux drivers, and the only one for a long time, back when tablets were new. Not sure how it is today.
Wacom still has great Linux support, but now there's OpenTabletDriver which supports many other tablets [1].
I have also switched to using a Wacom tablet instead of a mouse more than a year ago (with Linux) and my only regret is that I did not have the idea to try this many years earlier.
In comparison with a mouse, a stylus is much more comfortable, much faster and more precise.
To be used as a mouse, the tablet must be switched from the default "Absolute" mode to the "Relative" mode, when the tablet mimics a mouse.
This can be done by a script automatically executed at power-on, which may also choose how the buttons should behave, if you do not like the defaults.
For instance, for my Wacom stylus I set the tip to be left click, the first button to be right click and the second button to be double left click. Actually doing double click with the stylus buttons is more inconvenient, so it is more comfortable to map the single click on some button as a double click.
The tablet works well as mouse in absolute mode, too. You just need to get used to the different way of positioning (with the tablet as a small representation of the screen).
My kids even prefer that with a big (and pretty old) wacom tablet.
Yea I use it in absolute mode and it works nice. I didn't even know it could be configured to a relative mode, and at this point it would be confusing for me, but it could help others get used to it better since "what's intuitive" is different for everybody.
(P.S.: I apologize for other unanswered comments in the thread; I can't reply anymore because of how many days have passed since.)
Much too high learning curve for a wacom tablet. Getting used to writing "blind" while looking at a screen definitely takes time to get used to.
Give them something with a screen instead (e.g. cintiq knock-offs, ipads, samsung tablet, surface) or a webcam mounted to record a whiteboard/blackboard or mounted overhead to record a sheet of paper. That might also help to get better audio at the same time.
Side-note: When remote meetings became necessary in recent years, lots of software/hardware solutions were improvised, not great, but workable and with a hope that better solutions will become available later. Somehow that did not happen and people are still "scratching unintelligible diagrams/equations with their mouse" because there is no standard, widely available software and hardware that makes this easy.
Agreed, I have ended up prioritizing stylus support so much that now every computing device I use supports one (although it started as a digital art thing). At my desktop I have a 22" pen display (a Huion kamvas, the wacom displays are pretty overpriced), my phone, tablet and laptop all support S pens, and I have a couple of older non-display pentabs too.
The impetus was from wanting to be able to practice digital art in free time regardless of where I am, but it has ended up being extremely convenient as anything can be quickly drawn up or written, easily shared with everyone else and does is trivially retained.
> At my desktop I have a 22" pen display (a Huion kamvas, the wacom displays are pretty overpriced), my phone, tablet and laptop all support S pens, and I have a couple of older non-display pentabs too.
I'm using a Samsung Galaxy Book 3 Pro 360. Personally I love it, the large screen and large touch pad makes it great for note taking and coding. Makes it as tolerable as it gets to not be at the triple monitor desktop setup at my desk (particularly when using the S8Ultra as a second screen). The battery life has also been more than sufficient for my needs (but since it's basically for web browsing, document editing, note taking, amateur level drawing and light client for SSH'd vscode, it isn't doing much). My main criticism would be it feels a bit delicate.
I had also tried the regular Galaxy Book 3 360 for a day, but I felt the screen was a bit small and not as sharp as I'd like.
That said, since EMR pens also work in-place of S pens, I'd guess that S pens will work on any device that supports EMR pens (minus the bluetooth air gestures, those aren't available on windows laptops). For me the value was the 'ecosystem' with my other devices which also happen to be from Samsung, including the ability to share the stylus between everything.
I have one, and flipping it from "laptop mode" to "tablet mode" adds noticeable friction, especially if you have e.g. a dock connected. Then again, so does having to carry around a tablet.
For an office job I'd take the external tablet, since my laptop would likely be plugged in all the time.
You could also keep it permanently in tablet mode and use an external monitor, mouse, and keyboard. Just don't underestimate the mode change.
Tablets need extra space only when replacing the embedded touchpads or trackpoints of laptops.
For someone who uses a desktop or who prefers mice to touchpads, a tablet does not need any extra space, it just replaces the mouse and the mouse pad with the stylus and the tablet.
There are big tablets too, but for replacing a mouse and for simple drawings a small tablet like Wacom Intuos S is perfect.
Tablets tends to emit heat, leaves fingerprint, your hand obscures writing, and expensive. Upside is it's more conceptually straightforward. To each their own.
Yes, exactly. And/or perhaps a Quest Pro. (I'm not kidding.)
In VR, you can point, draw, and share virtual desktops.
Otherwise, no one knows what the hell anyone is talking about, and perhaps get the wrong impression about one another.
I strongly disagree with RTO as ass-in-seat-mentality for knowledge work jobs that don't design or manufacture physical items. I've been part of fully WFH companies since ~2000 spanning up to 8 time zones. The quality of discussions requires the ubiquity of tools for expressiveness.
I have been really tempted to sit down and write a ot version of edotor.net so more than one person could edit a graph at the same time in a meeting/ discussion.
We have been trialing using it to draw graphviz graphs for discussion and it has been working very well both as an in meeting tool and as a reference later on.
Would be interested to go the Wacom route but my my handwriting is very bad and only getting worse
What are you using for note taking? I while back I bought a small Wacom tablet for this very purpose, particularly being able to quickly sketch out diagrams while in in meetings, but ended up giving up because I couldn't get the hang of using the tablet.
I'm pretty sure it was a tooling issue rather than the tablet itself, and wouldn't mind taking another punt at it.
I have the medium Wacom. I think the small size would be uncomfortable.
When I was a prof, I used the Wacom on linux with OpenBoard [1] to teach online for two years of the pandemic. My work gave me a Macbooks, but OpenBoard has some weird bugs on MacOS. So I am using GoodNotes, which is very annoying, but the best of what I tried. In another life, I would dedicate a few years of my life writing a decent note taking app.
> I have the medium Wacom. I think the small size would be uncomfortable.
I have a Wacom Intuos S.
Sample size 1, but I haven't been inconvenienced by its size, even while handwriting or drawing at Krita.
On one hand, I don't think a thought like "this would be easier with a bigger tablet" has ever crossed my mind; but on the other hand, it's also true that I haven't tried anything bigger, so my only point of comparison is tablet vs mouse or tablet vs whiteboard/notebook.
I haven't also tried the S one. But my intuition is the following.
The surface of the tablet is mapped to your screen in terms of input. The Intuos M is just a bit smaller than 13 inch laptop screens. So what you see on the screen is roughly the same size as what you draw with your hand. Additionally, while writing at normal pen/paper size, my hand moves comfortably from the left of the tablet to the right as I write across the whole screen.
If I had to use a Intuos S, then I imagine, I would have to write a lot smaller with my hand, but then have it appear as bigger on the screen. But my hand would not move a lot, and making tiny characters would tire my hand out faster. I think my brain would get used to it, but it will still be a jump.
It's just a need to train hand-eye coordination. Practice blind contour[0] on the tablet for a few minutes a day for two weeks and it'll come around.
Contour drawing is not taught in primary education, and it really should be: it generalizes on how you learned to write by learning some muscle memory and then playing it back to make a mark. Nobody who can write should be going around saying "I'm untalented at art, I can't even draw a straight line".
What's your OS? On Windows, Nebo is pretty good. Rnote is the best of FOSS, but it lacks handwriting recognition if you need it, at least for now. For hybrid workflows (tablet + keyboard) Obsidian also has something to offer, Excalidraw plugin in particular.
>I'm pretty sure it was a tooling issue
Depends on whether you want shape/diagram recognition or not. If the only thing you need is free-form drawing, you can use just about anything.
I just tried Rnote. Seems quite decent. But on MacOS, it seems to be bugged. Instead of a tiny pointer/eraser/other tool showing as the pointer, it continues to show the OS mouse pointer.
I will try it on linux later. Hopefully it will work there.
My initial gripe is that there are three different toolbars, all separated from each other. I want to change tools and their settings quickly, not move my hand across the entire screen. For example, select brush tool on bottom toolbar, select size on the left toolbar, then select color on the top toolbar.
It didn't hurt that the comment section[0] for the blog is powered by the fediverse [1], so Greg KH responded to the post [2] pointing him towards writing that email and tips on doing so along with many other tech savvy individuals. This issue is being seen all over the place.
It’s email. How is it a poor experience? You literally just type out a description of your problem into your favorite email program, one you have used thousands of times in your life, put the address of the mailing list in the To field, and send it. Then when someone replies, you get the reply as an email. If that’s a poor user experience for you, then you are using the wrong email program.
Where am I supposed to look for already-reported bugs? Where do I send that email? Do I need to CC people, and if so who? How am I supposed to format my email? What information am I required to include? How will I receive updates: will people CC me, or do I have to subscribe to a mailing list - which one of the 291; how do I avoid getting spammed by hundreds of unrelated emails a day? Is my email client even allowed? Am I using a domain which is on some kind of ban list?
Contrast that with the Github or Bugzilla experience: make an account, click "report issue", follow the wizard which asks me to provide all the information I need. I am automatically subscribed, and will receive updates via email.
The whole report-via-email might work for experienced kernel developers, but for a regular user trying to just report a single bug it is way too much of a hassle. If I ever encounter a kernel bug, I would go out of my way to avoid directly reporting it upstream - I'd just file it at my distro and let the maintainer deal with the upstream reporting.
The instructions are fifteen thousands words, and don't even answer all of those questions. That's worse than no instructions at all, if you ask me.
You'd be hard-pressed to call me "lazy", to be honest. I'm more than happy to dig into the kernel source to determine the cause of such a regression because I actually like doing that kind of thing. I've submitted several single-digit-line patches to large projects to solve exactly this kind of issue.
Spending a Saturday morning trying to figure out a kernel bug is quite enjoyable. Spending a Saturday afternoon trying to figure out how to submit a bug report or patch is not - especially when it is literally a 5-minute process for the vast majority of other software projects. If I have to deal with that much bureaucracy, I'll just keep my patch to myself.
it's an unsearchable waterfall of noise, especially if you have to subscribe to multiple. It's such a chaotic and ephemeral way to communicate about things that should be orderly and timeless. I honestly cannot imagine trying to make a case for mailing lists when there are more robust and intuitive options available.
Saying "it's email" means nothing. Just because you announce the name of the tool doesn't make it the right tool.
It’s exactly as chaotic or orderly as the people who are talking to each other, and it would be no different if those same people were using a bug tracker.
And what do you mean by unsearchable? There is a search box right there for anyone to use: https://lore.kernel.org/lkml/ Long time subscribers to the list would do a local search from within their own email program, of course.
How do you search for existence bug reports to see if someone else has hit the issue? How do you subscribe to an issue to know if progress is being made on it? How do you keep track of all of the issues. Why is it the user's job to traige bugs to the right person? Microsoft doesn't reccomend you to find the email of someone on the NTFS team if you find a bug in Window's handling of NTFS.
The part about writing and sending the initial is passable using email, but everything else is terrible.
Yea, it looks like they sent their original email to several people, but failed to send it to the list. And they didn’t include any of the specifics in the email (such as kernel versions), instead giving a link back to their blog post. Whether you use email to report a bug or a bug tracker, you _must_ include all relevant information in the report itself. Even if it means repeating yourself, or coping and pasting from your blog.
Edit: Actually, they might have remembered to CC the mailing list, but since they use Proton Mail it probably sent the email encrypted. Don't send encrypted email to mailing lists.
The lists reject HTML emails entirely, and most mail clients don't make the choice between sending plain-text and HTML emails obvious (if they offer it at all)
Ideally, mailing lists would make some effort to keep the plain text content in HTML emails rather than just throw it away. If lynx can render full pages in a console, surely we can degrade HTML down to plain-text without too much effort.
Rejecting people who have not taken the time to setup their email client is tradition, but not very helpful.
You track the issue by waiting for replies to your email. With a bug tracking system you would wait for replies to the bug report in exactly the same way.
It is not the user’s _job_ to triage bug reports or direct them to the right person, but it is _helpful_ if they can take a minute to peruse the list of kernel modules and find out who the maintainer of the most relevant module is. By adding that person to the CC list of your email, you ensure that they will notice your email right away.
Microsoft has hired hundreds of people to serve as liaison between customers who pay for tech support and the developers who write the code. There’s no way for you to break through that barrier and talk to an NTFS developer directly because Microsoft prefers it that way. The Linux kernel developers cannot afford and do not desire to have that level of bureaucracy in between them and the world.
>You can search the mailing list archive via the web page
Not all bugs are sent to a mailing list. From what I can tell it is reccomended that you email the maintainer directly. You can't search for those direct emails. Also I'm not sure that search even is for the place bugs are reported, nor am I confident that it would do a quality search instead of just grepping emails with no ranking.
>You track the issue by waiting for replies to your email.
If you did not make the initial report there isn't a way to get a notification when there is a reply to it.
>There’s no way for you to break through that barrier and talk to an NTFS developer directly
You can just email them. There is no barrier that prevents your email to them or prevent them from talking to you directly.
>The Linux kernel developers cannot afford
The Linux foundation made >240M in revenue last year. They can afford people to triage bugs.
> If you did not make the initial report there isn't a way to get a notification when there is a reply to it.
Sure there is. Send an email and ask for a status update. Be polite about it, and ask for specific information. If you suspect that the work was done and it was committed, ask whose tree it is in. From there you can follow the commit as it is merged into trees owned by people higher and higher in the community, until Linus himself merges it into the next release.
>> There’s no way for you to break through that barrier and talk to an NTFS developer directly
> You can just email them. There is no barrier that prevents your email to them or prevent them from talking to you directly.
If you know who they are, sure. What are you going to do, go on linkedin and hope you get lucky?
> The Linux foundation made >240M in revenue last year. They can afford people to triage bugs.
The Linux Foundation does not run the development of the Linux kernel. They provide support services (like the kernel.org webpage where you can search the mailing lists), legal services, advertising, conferences, etc. The actual development of the kernel is done by volunteers, many of them paid to work on the kernel by their employer.
If you want bug triage or other support services, you should pay for it. Contact Red Hat or whoever and they’ll get you started.
>Sure there is. Send an email and ask for a status update.
This sucks compared to something like Github where you can just visit an issue or subscribe to it. People don't want to have to SEND AN EMAIL to see the status of something.
>The Linux Foundation does not run the development of the Linux kernel.
>>> If you did not make the initial report there isn't a way to get a notification when there is a reply to it.
>> Sure there is. Send an email and ask for a status update. Be polite about it, and ask for specific information. If you suspect that the work was done and it was committed, ask whose tree it is in. From there you can follow the commit as it is merged into trees owned by people higher and higher in the community, until Linus himself merges it into the next release.
> This sucks compared to something like Github where you can just visit an issue or subscribe to it. People don't want to have to SEND AN EMAIL to see the status of something.
Which do you want? Notifications or to visit a website without bothering anybody? If you want a notification, then send an email or just subscribe to the list. You can have your email program or email server move all the email from the list to a folder, and mark everything not in the thread(s) you care about as read if you want, just so that you don’t have to waste your time looking at the emails you don’t care about. Or you could talk to a person. Is that really such an unthinkable action to take?
You can also mirror the content of the mailing list in several ways, such as by cloning a git repository or downloading mbox files, or by using an NNTP server. See <https://lore.kernel.org/linux-input/_/text/mirror/> for instructions. Feel free to wire that up to any type of automation you want. Make your pager go off any time anyone mentions your pet bug. Make it dim your lights, turn on the RGB LEDs and the projector, and play “Bad to the Bone” at the loudest possible volume when your bug is fixed. Have fun with it!
>> The Linux Foundation does not run the development of the Linux kernel.
> But it does fund some of its development.
All it does is pay people to work on the kernel, it doesn’t mandate how that is done or what gets done. If you want someone to hold your hand so that you don’t have to subscribe to a mailing list, there are several support companies that will happily take your money. Or if you think a lot of people want a bug tracker so that they don’t ever have to talk to another human being, maybe you should provide that service yourself.
All your suggestions are orders of magnitude more effort than 'click a button to get email notifications if someone comments on the issue'. That's what people are complaining about, not that it can't be in principle done if you duct tape enough things together yourself.
I disagree. Sending someone a quick email is not an order of magnitude harder; both are the work of seconds, maybe minutes if you have to find the right email or bug report first. But if you think that it is, maybe you should offer that service. Give people a website where they can click on a button on any email in the mailing list to subscribe to replies as if they had been CC’d in the email itself.
>If you want a notification, then send an email or just subscribe to the list. You can have your email program or email server move all the email from the list to a folder, and mark everything not in the thread(s) you care about as read if you want, just so that you don’t have to waste your time looking at the emails you don’t care about.
This overly complicated. I consider myself more technical than 99% of people and even I couldn't tell you how to do this. How do you except a normal person to be able to figure this out. Do you think your parents could figure this out if they encountered a kernel bug?
>Or if you think a lot of people want a bug tracker so that they don’t ever have to talk to another human being, maybe you should provide that service yourself.
There are plenty of source forges which offer this. Look at what KDE or freedesktop have done with hosting their own.
> This overly complicated. I consider myself more technical than 99% of people and even I couldn't tell you how to do this.
You don’t even know how to filter the email you get? That is extremely sad. And yes, my parents do know how to set up their own email filters. On the other hand they would probably call me or one of my brothers if they encountered a kernel bug; free family tech support beats troubleshooting any day of the week :P
> There are plenty of source forges which offer this. Look at what KDE or freedesktop have done with hosting their own.
That’s not what I meant. Most kernel developers have no interest in bug trackers, self–hosted or otherwise. If you think that there are enough people who do, you could act as an intermediary by running one yourself and charging for access.
Most email clients have powerful filtering options. And since this is the tool of the trade for kernel developers, they use this power. If you did work on a tool that used an email list as bugtracker, you’d likely have a well-working setup for that.
And when you have setup your email client, it beats github issues in time efficiency any day.
Great example of how Linux evenings randomly come about. Someone, somewhere, did a thing, and now user needs to find out who did what, and why it happend, and how to fix it by themselves.
While with proprietary software, someone, somewhere, did a thing and now you need to change your whole workflow because it is the new "only way to do it". But you will like it because marketing said so.
Absolutely. I may not be happy about the people that do the free work for me doing work I wish they didn't do. But at least I'm sufficiently in control that I can roll back, or that if literally the whole world hates the change that it can be forked.
Whereas Excel had the bug with date format detection that the entire world had to work around with no chance of getting it fixed. The genomics field had to change the name of a gene because even though they all knew it and must have had some population of people that had the skills to fix it, just couldn't until Microsoft got sufficiently embarassed by it after decades (https://gizmodo.com/microsoft-fixes-excel-feature-that-force...)
Still less painfull than spending hours researching to find something that works, only to break at any kernel update.
Got my first GNU/Linux in 1995 with Slackware 2.0, kernel 1.0.9, got fed up by the time Windows 7 got released, still own a Asus 1215B Netbook with Ubuntu, with its own share of kernel updates breaking graphics and wlan.
Anything else, happy with Samsung, LG, Nokia, Apple, Google and Microsoft overlords.
So avoid that for giving lectures, I bought a refurbished laptop with Linux (Trisquel) pre-installed. In the past 5 years it did not give me trouble yet.
Everyone frantically rushes to archived versions of Wacom drivers and starts installing random .reg files from the Internet when Microsoft do this(they did couple times).
This is an example of a Fedora evening, which is a "bleeding edge" Linux distribution. It wouldn't happen on eg. RHEL or its free clones, or probably even Debian stable. Of course shit will break sometimes on Fedora, and you will spend a little time trying to figure out why, or working around it.
No point running a bleeding edge distro and then having a sook when things break. The correct procedure is to file a bug report, downgrade to the last known kernel that worked correctly, and wait for a patched kernel to appear in updates. Or run a stable distro if it's such a problem. I don't get why "bleeding edge Linux distro has breakage" is such exciting news for HN. This is pretty much a non-story.
Rock and hard place. If you run something "well-tested" on a new platform (e.g. latest Thinkpad or XPS) you possibly aren't going to have sound, a webcam, a functional trackpoint, accurate color profile, mobile broadband, a fingerprint reader, proper sleep, and, and, and
It's long established that Linux will lag eg. Windows in terms of driver and hardware support. It's been that way since the 1990's. This is one of the few downsides and not news. You can always run a mainstream desktop OS on the shiny laptop and run Linux in a VM (eg. WSL2) until your hardware is supported by a stable distro.
$ modinfo -p usbhid | grep quirks
quirks:Add/modify USB HID quirks by specifying quirks=vendorID:productID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp)
Depends, my wlan driver on Ubuntu still has connection issues with my router, it is the only device in the house that requires being occasionally plugged into LAN cable.
It is also the only one using GNU/Linux, the TV/WebOS and Android/Linux devices, alongside Windows, just work.
If a 'fix' broke something (and it's not for something like a major security issue), then it is customary to revert the fix and go back to the drawing board
I can see that this is a complicated situation and OP was a special case that had not been affected by acccident, but those are excuses
If you upgrade your kernel and you don't have any out of tree stuff, by policy nothing should break, orherwise it's the kernel's problem.
“Never break userland” is more of a strong guideline than a hard rule, even if Linus has sometimes made it sound otherwise during a heated gamer moment. The fact is, kernel devs break userland code all the time, sometimes because the alternative is worse, or sometimes because a bugfix broke something and no one noticed until much later and it was decided not to revert the fix because it would now break other things to do that. Try to run an entire large userland from 2001 on a modern kernel and tell me how that goes.
Mistakes are human. Certainly a lot of bugs slip through, and that's understandable, software is hard.
That being said, I find that people tend to take the no regression rule pretty seriously, if you bring a valid complaint. It makes good sense. We don't want to give people a reason to stay on old kernels even more than they do today (this post written on an ancient Android kernel, chock full of out of tree drivers). We can at least save people from pain when it comes to in-tree drivers.
I think we really all benefit from that policy. Even if it sometimes keeps some less than perfect workarounds in the code
I mean, for whatever stupid and obscure reason, the manufacturer decided to hard-code the eraser button like that. The device was designed to have two erasers. If you used that tablet on Windows and switched to Linux, you'd notice the device wasn't working like it was supposed to. I can see why one would consider that a bug.
One user asks "why is my right click an eraser now", another asks "why is my eraser a right click on Linux". Which one is right?
To resolve this, the devs could've added an easy setting somewhere to control this behaviour, but I still think this can be considered a reasonable bugfix as the manufacturer decided on this stupid design. Linux drivers used to hack around that, but that's a classic XKCD 1172 problem.
We had a fun one a couple years ago where a kernel bump turned our USB touchscreen monitors into trackpad monitors... (i.e. touch input behaved like your laptop trackpad) Thankfully I was able to figure out a udev rule via trial and error and get that fixed easily enough. ChatGPT probably would have saved me some time there had I had it at the time. Deploying that to hardware in the field was the messy bit (but still automated, so that was a win).
Oh don't get me started. I got a Corsair Claw Gaming mouse and Rocky Linux 9 does not have a simple way to map the buttons to events. Corsair does not provide Linux software for it. Yes I tried all kind of mapping programs to no avail. My chromebook old chromebook tablet (32 bit) has a stylus and works okay. I won't upgrade, I know how those upgrades break non-run-of-the-mill external devices APIs.
OK, I will byte, have you tried Input Remapper[1] ?
I think most of your problem is coming from using Rocky Linux, it is much easier to find support on Ubuntu derivatives for tools made by the community in general.
When using proprietary software on windows/mac, somebody somewhere decides how you’ll be living your life from now on and you just suck it up. They might even decide that your perfectly working hardware is deprecated and drop support. Or decide that from now on you have to pay a monthly toll to keep using their software. And you have no way to voice on the matter.
Windows or macOS is the alternative. You don't get to trot out the "but big software will decide how your devices work" bogeyman when Linux literally just did the exact same thing to this person.
The point there is not that the decision will be made - that can happen anywhere. The difference is that in one of those, you can still patch the old behaviour. In the other two you can only raise a bug and hope somebody cares.
Well in a windows or macOS case, there is usually no workaround. In this specific case user can still boot the old kernel version or decide to compile the old module.
On the other hand, if your livelihood depends on your OS working correctly you AND you don't want to be expected to rebuild kernel modules or to know how to do it, maybe you should be considering paying for enterprise support. A redhat or suse engineer would totally send him instruction and/or rpm/source code so that a clueless user can fix his computer.
"I'm a blacksmith and I expect every chef to be at least able to forge their own knife."
Uh, no? You are completely out of touch on other (non-programmer) people's backgrounds. They don't know what a kernel or even a terminal is. It's more than just copy-pasting commands from SE.
A chef, that for whatever reason cannot forge their own knife, better make friends with a blacksmith, and think about what they want when they want them to make them a knife.
They should not expect blacksmiths around the world to read their mind and make them knives for free. They should expect it's their own responsibility.
> Krita on Linux to paint shouldn't be expected to rebuild kernel modules.
The other-side of the coin is that if your using Linux, you should expect that such things happen without your desire. And that if you wish for the previous feature you'll have to nose-dive in to if you want to fix or just revert back to the previous version. You shouldn't, but here we are.
At the risk of downvotes, I would also say you shouldn't really need to update the kernel either. Unless there is really a feature required, or extreme-security vulnerability of your current version, exclude it.
That was the past-beauty of Linux, you didn't need to be on $latest; that was Microsoft's realm, always requiring updates. If it worked you left it be for this exact reason. Every day I look at my iPhone and everyday there's a batch of updates for my apps sometimes twice on the same day for the same app and I don't use many.
The current fearing update culture we live in is terrible.
Because, as shown here, there's no real testing for this stuff. You're the forever-beta tester, fearing every update.
This has always been my experience with Linux, but I also don’t buy computers, and peripherals, specifically for Linux, which seems to be a very heavy requirement for a good experience, as the perpetual year of Linux on the desktop has unrelentingly shown us through the decades.
Because Linux is a community ran, free. You can't demand a volenteer maintainer to keep it the way you like it. You either accept it, keep back/change or incentive the maintainer.
If using the second button as a eraser is the de-facto feature, then it's likely it's going to be implemented the same everywhere else. Or could simply be the maintainer doesn't like his art work, a sadist and changed for the sake of pure evil.
Either way you can't expect anything to stay as you like it if it's free. It's why forks/distributions exist.
The catch is that this is antithetical to what Linux 'wants to be[0]'. Linux cannot become an every-man's desktop OS when issues like this are allowed to occur.
[0]Or what at least some Linux evangelists want it to become
Linux is just a kernel to create an operating system in the way the creator wants it to be. You either hook on that train, find another distribution that makes you happy or make your own.
Maybe the author should change to another distribution that doesn't have the change applied.
> The other-side of the coin is that if your using Linux, you should expect that such things happen without your desire.
Please define "linux"
What happened to the author while using Fedora wouldn't have happened while using RedHat Enterprise Linux or any other distro with long term support of an existing kernel. Besides author can still boot with old kernel version.
I think posting about this problem is quite a reasonable approach. Several kernel maintainers seem to have already noticed this, and gregkh provided instructions on how to potentially resolve such an issue (send an email to the maintainer and the appropriate mailing list).
"Just recompile your kernel" is how Linux people convince other Linux users to install Windows or buy a Mac.
> "Just recompile your kernel" is how Linux people convince other Linux users to install Windows or buy a Mac.
Well I'm not really proposing he does it, I'm just saying he should ask for someone to help him do it.
If I understand the post well, his workflow was relying on a bug in his pen driver. That bug got fixed. It's just the way things move forward, it happens on Linux, Windows, or any software really.
The sane solution is just to rebuild the old driver (not kernel).
OT, but PSA: If anyone has issues with tablet PC screens feeling slimy and uncomfortable to draw on, try "paperlike" screen protectors. It has grainy finishing reminiscent of tracing papers and office desk surfaces, and significantly improves drawing feel.
While very annoying, it is possible to create an evdev based wrapper around the input, that can remap any of the signals as you wish (I know it's possible cause I've done it).
But, having to flip a stylus around just to engage with the eraser functionality in the app is perhaps an outmoded concept. The author makes it sound like the fault out-of-touch stylus-lite business users, but I disagree. Some artists erase a lot as part of their workflow, particularly during certain parts, and map this functionality accordingly..
Yeah this is why I don't use Linux on the desktop. 25 years of trying and at least once every 6 months something stops working completely or doesn't work out of the box properly. I gave up.
It's really a failure of vision by hardware makers. Intel especially should have aggressively backed Linux Desktop because:
1) it would have helped invert the subservient position they had with Microsoft in general
2) would have allowed Intel to push out an demonstrate hardware features in an OS without waiting for Microsoft to support it two years down the line in some service pack
3) probably would have kept them up with consumer hardware and the smartphone thing wouldn't have blindsided them
4) probably enabled them to get more of their peripherals businesses (which they constantly acquire and shed)
5) enabled cheaper low end devices where the Microsoft tax is a quite large percentage of the device cost
6) would have enabled them to be in the ARM game if they wanted to, IoT with Atom processors, and tons of other markets
Qualcomm or some other ARM vendor should have done it to
1) have a real alternative to google controlled Android
2) get ARM out to more consumer devices
3) get their hardware features demonstrated more quickly
Google should have done it (yeah ChromeOS sucks)...... well, we I'm shocked ChromeOS hasn't been dropped yet and Google would never have stuck with it.
But none of that matters now, it should have been done 20 years ago. And Apple seems to be the only hardware company that does software well.
Agreed. Here is a list of things I ran into in my past attempts to use Linux as a daily driver:
* random errors coming out of nowhere on Linux after a refresh installation + package update
* IME not working (Asian language)
* IME providing very low quality suggestions leading to slower typing speed
* scaling issues (fractional scaling)
* random freezing on gnome
* No sound from speaker on a laptop (driver issues)
* issues with connecting to 802.1x wifi (in a certain distribution, was able to get around via command line)
* not being able to find one decent pomodoro app -- the one in the Ubuntu store doesn't work, like, at all
* window management is way behind Windows
That's what I can think of right now, but if I spend more time I can come up with 30 more. Windows and Mac have their fair share of bugs, limitations and weirdness, but nowhere nearly as bad as this.
Nah, only when wanting to use exotic hardware/software that is not supported by the vendor. The article author wouldn't have had this issue with a wacom.
I have those issues with power management and graphics drivers on stock Intel machines. The real problem is the kernel QA is shite and the vendor packaging QA is shite. Microsoft are actually orders of magnitude better and that's saying something.
I don't know. My professional laptop on windows decided one day to only discover (or not) randomly the external monitors connected to my usb-c dock (same manufacturer as laptop). If I am booting on windows, every time I boot it is like rolling a dice to know if my screens will show something.
Do not happen on Linux on same laptop.
So I would say you have rose tinted glasses when using windows or just got lucky with it and unlucky with linux.
I'd say you probably should think about it the other way -- you only get decent Linux desktop experience if everything is supported by the vendor. Just look up on HN what kind of trouble people run into when installing a Linux distro on their laptop. People go as far as recommending very specific models from certain brands because everything works as expected on those laptops.
- graphics tablet digitisers generally are not and don't include touch digitisers
- tablets are not touch screens
- a stylus (tip) isn't a button
- a stylus can have buttons
By convention, stylus tip interactions are "tools", which seems to be what Linux' BTN_TOOL_* codes are meant to mean. A button on a stylus should never be (directly) translated to a tool -- like how the ~5th button on a mouse is `BTN_EXTRA`, not `BTN_MOUSE`. In this particular case it looks like the thinking is: the device has 2 event codes (which we know as the stylus tip and the barrel button) and it's a stylus^wdigitiser, so map device[0] to `BTN_DIGI` and device[1] to `BTN_DIGI + 1`.
editendum: the thing about the BTN_EXTRA doesn't really map... The "digitiser" event codes are being treated in the same way as mouse event codes (device[i] => event[CLASS + i]). The issue is really that the barrel buttons have no (dedicated) event codes.