Nah, wrangling angry pixies and sniffing magic smoke is kinda my day-job. Nothing to "beware" of really, just keep one hand in your pocket and a fire extinguisher change of trousers believable excuse handy.

Not quite my jam, but close enough for government work. \m/

They were actually an intentional thing for a bit, back when active power-delivery negotiation specs were still a total mess.

If devices couldn't agree on a current limit, they would default to 100mA (which sucked), but there was a dumber standard that pretty much everything understood...
Bridging the data pins with a <200ohm resistor indicated a device was a charger that could deliver up to 1500mA, and it saved the manufacturer on both the power-delivery IC and the two extra wires.

This is supposed to happen inside the power supply/charger rather than a generic-looking cable of course, but Chinese manufacturers aren't exactly well-known for adhering to spec... So a few "magic" cables that would make your not-entirely-compatible (or just buggy) charger and device settle on an amp or so made it into the wild, as did cables that look like a standard USB cable but aren't, because they shipped with a charger and it saved a few cents to use normal connectors but only two wires.

I've made such cables myself, they're kinda handy if you want to get an old phone charger or powerbank to "just gimme power" for not-really-usb purposes (or blow fuses on old motherboards, to be tried only if you like fiddly soldering ).

All this went away with later USB specs and fast-charging, which mandate active negotiation.

A USB data cable, obviously. Same as you would use for ADB or fastboot any other time.

Same as flashing any other ROM, after doing whatever your hardware vendor requires to unlock the bootloader.
e.g. Enable debugging -> OEM unlock -> bootloader unlock -> reboot to fastboot -> fastboot flash [partition] [image file] (repeat as needed) -> reboot to recovery bootloader -> wipe /data ("factory reset") -> reboot to OS.

Why? Just use fastboot and follow the instructions on the grapheneos site. They even give you a shell script so you don't have to go through each step manually.

On a pixel specifically, no. I'm not about to fork-out for any "flagship" phone, let alone one made by Google.
Aside from vendor specifics like bootloader unlocking, android is android, fastboot is fastboot, and flashing a rom is much the same as it ever was. If the install page is anything to go by, this one is about as uncomplicated and "vanilla" a flashing process as you could want.

Money, obviously. Mostly from RedHat, and a few other commercial entities with interest in a desktop GNU/Linux product. Having a cohesive, tightly controlled, recognisable GUI environment - one GUI environment - is a pretty big part of that, and cruical to offering the likes of RHEL for both servers and workstations. GNOME and freedesktop are RedHat these days, and systemd+wayland+pipewire+GNOME(+LGPL/MIT licencing) is what RedHat envisages a user-friendly, sellable and support(contract)-able Linux desktop to be.

Indeed... Though with FOSS the "developer or not" bit is still somewhat less black-and-white than it is with commercial software. You can patch or fork and be your own "developer" if you have the motivation, but often it's (artifically) difficult enough that "walk away, go do (or use) something else" is the smarter choice.

What these (relatively) modern "open source" organisations are doing is trying to have thier cake and eat it - i.e. benefit from free code by unpaid "not a developer" contributors, while also gatekeeping all the decision making. Come to think of it, much the same thing Redhat was trying to get rolling 20 years ago.
That's what most of the co-ordinated attacks on forks, alternatives, and even silly little things like application theming are really about. What's ours is ours, and what's yours is also ours, you will eat what we give you and be grateful. Because we have more money, more developers, and more to gain from branding and vendor lock-in. Politics is a smokescreen, it's all about image, money and control.
Oh look how they flip out when somebody, uninvited, dares to play with one of "their" bigger toys. See how quickly Godwin's law, cancel-culture, and plain-old slander are mobilised to shut it down.

You can accept this situation as status-quo and get on with life, you can go somewhere that hasn't been infiltrated (yet) and hope it holds out, or you can wear the hair-shirt of "desktop GNU/Linux 15 years ago" (i.e. lots of choice, but also lots of work and lots of jank) by sticking with the original FOSS spirit and becoming a developer, amongst the many projects small enough and esoteric enough to escape notice and remain the domain of the true software nerds...

Or one can just rage ineffectually about it all I guess - but it won't achieve anything, and I'm pretty sure this board isn't meant as a therapy session.

I'll be nice to zapper just as soon as he stops calling people names. It's obnoxious.

Also, @blackhole: Ahh, a nice refreshing glass of reason in this desert of politics and vitriol. +∞

Syntax matters when it comes to code quality, semantics and politics do not.

I don't know if I can trust people who put more emphasis on politics, "red flags" and similar buzzword rhetoric, and linguistic hair-splitting than code quality to present a rational argument one way or the other.

Sure. I await your reasoned (read: technical rather than political) argument for one over the other (also your xenocara debian packages, sans BSD-specific code) with bated breath.

Oooh, really filling out that buzzword-bingo card today, aren't we?

The answer is right there, in gigantic font, at the top of the README for the (archived) github repository you are cloning:

The module you are trying to compile references functions that no longer exist (at least under those names) in your installed (6.1.0) kernel. Either fix it yourself (out of scope here) or use a codebase that is maintained for current kernels.

What difference would it make, you do the same...

Everywhere you go.

Then, if anyone should dare propose an improvement to this supposedly terrible situation, out comes the...

You moan, but you do not do. You rubbish free software, but you do not work on it, even to help yourself. You insult groups and individuals, you belittle their achievements, but you will not even attempt works comparable to theirs.

Your sole contribution to a thread asking how to do a thing is to state that you're not brave enough to try, but someone else might... And even there, you misrepresent my statement.

In any case, I'm done with this thread, and I'm tired of the whinging and politics on this board in general. I'm currently running xlibre on Gentoo, and If anyone wants to try it on Devuan I invite you to read the extensive Debian packaging docs and figure it out.
Otherwise, feel free to hop over to a distro/board/irc channel with less moaning and more doing.

Oh that wasn't meant for you, you're making things. It was for the "I bet it could be done", "not brave enough", "I do hope that SOMEONE will", "above my pay grade", "Perhaps you would like to" bikeshedding crowd.

I built Xlibre on Gentoo, because that's my main these days and the only Devuan installs I have are headless servers I'm not about to screw around with for something they wouldn't even use.
There is now an overlay hosted at github.com/X11Libre/ports-gentoo, so trying it on Gentoo is no more difficult than installing any other live build.

I see no reason the xlibre devs would be against a similar arrangement for Devuan, were somebody with an appropriate build environment to adapt the Xorg spec files and build test packages. That shouldn't be particularly difficult to do (though personally I find the Debian packaging workflow somewhat convoluted and unpleasant), since the project structure is still very close to Xorg.

I mean I could probably do it in a VM or chroot, but not to put too fine a point on it... That's a lot of mucking about and the lack of effort from anyone else around here (who, unlike me, stand to benefit directly) isn't particularly motivating.

Exactly this ^
You claim Xenocara is "the best option", but offer no technical arguments or comparisons to back it up. You claim it "could be done", but don't actually do it, even just for testing, even just for yourself.
You claim Xlibre "could be good", but you haven't tried building or using it... And your "doubts" are vague aspersions on the lead developers politics, rather than a technical assessment.

Why don't you try compiling that, if it's a project you want to promote?

As usual, it's all just talk, all just pontificating on what other people should or shouldn't do, passing judgement on people you have never met, and minor variations of "xyz developers I don't know are assholes/scumbags/[insert insult here]".
Go contribute to the project in question, go work with the people concerned... Then maybe you get to call them names. Raging from afar is pointless and childish, regardless of how easy it is to spit at a faceless organisation you have no real contact with.

I for one do not give a fat rat's behind about the "principles in place" or whether or not the lead developer is a [facist|furry|wears a gimp suit on sundays], I care about ability, technical merit, and whether or not a piece of software is a: solving the problem at hand, and b: copyleft licenced so it can be forked if needed.
If something looks interesting, I'll try it. If there aren't distro packages yet, I'll build it. If it's promising, I might even try to contribute to it. I'm not an accomplished C/C++ coder by any stretch, but you don't always need to be to contribute in a useful way - case in point, even building and testing on different platforms can be productive, assuming you report any bugs you find.

So, how's Xenocera working out for you on $distro_of_choice? Any problems getting the code built? Any bugs to report or technical suggestions to pass upstream?

Ed. Thought that might happen... While I'm still trying to solve a bunch of nonsensical GPU crashes (result: not Xlibre's fault, it's a power management bug in the amdgpu kernel driver), Stefan goes live with an Xlibre-git overlay for any clown to try it out.
This is why I've largely moved over to Gentoo, where the arguments are just a smoke-screen for sneakily getting stuff done.

Well somebody has to actually test the thing, no? If we all just sit around waiting for the magical pixies to do everything, nothing gets done.

To be fair, wayland is *mostly* usable... But my own year-or-so living with it came to an end fairly recently, because upstream apparently has no interest whatsoever in getting from "mostly" to "fully" usable, or considering any use-case beyond "works for normie tasks on my laptop/corpo-drone workstation".
Every single proposition or pull request furthering feature-parity with X11 or backwards compatibility of any kind results in endless stonewalling, recursive arguments, and NIH bullshit. One can smell the "Desktop Linux belongs to us, toe the line or GTFO" excreta dribbling down from Redhat and IBM suits a mile away.

So back to a display server that works it is... And FUD aside, Xorg still does.
Not "works if you use the right compositor on the right day of the week".
Not "works if the app you want to use has been updated in the last 5 minutes".
And certainly not "works if you squint a bit and ignore broken DPI scaling, janky session restore, buggy clipboards, screwed up window placement, missing features, and general dogs breakfast of competing, poorly concieved, partly implemented protocols"...
No, Xorg *just works*. It even works for 20 year old software, with minimal (and often no) changes... Imagine that.

So far, I can't really tell the difference between Xorg and Xlibre from an end-user POV, which is exactly as it should be.
Meanwhile, the "X is insecure" apocalypse is still stubbornly failing to materialise. I'm sure it sucks for somebody somewhere when reality gets all uncooperative like that.

I'll be keeping a dual-stack around in case wayland ever grows up (15 years and counting), but I'm not going to hold my breath.