Over 30 years ago, I was doing some OS9 (Microware, not Apple) development on a 68k embedded target. I needed a PIO driver that could do bi-directional I/O. The OS came with a PIO driver, but it wouldn't let you switch directions. I approached the vendor with several options:
1) I will pay you to write another driver with this functionality.
2) License the driver source code to me and I will do it.
For reasons I do not remember, they would not do either.
I ended up reversing their PIO driver and implementing a version with the functionality I needed. I was uneasy about doing this, but we never sold or distributed the work so it was probably legal. (The development was for an in-house application with just one target.)
kind of weird to me that we still have so few phones that have started running mainline. there's a lot of postmarketOS phones, but my understanding is they Helium/libhybris which mixes in a ton of the Android support infrastructure/drivers to do the job. i could be overly concerned, but there being so few distributions & such specific distributions targeting phones is exactly the good this work OUGHT to be unlocking, & it just seems like progress in making that happen is disorganized / not really happening, alas alas alas.
getting a toe-hold in, where we start to see self-determinism on what our devices run, would be such a compelling & powerful vision. i really hope we can start to see that!
ubuntu touch targets the Pixel3. i'd be curious to know what they did. PinePhone & Purism really took it from the top, have their own hardware that starts in a more easy-to-work with set up. but I don't see why that would be required to get a decent regular linux distro (arch, debian) running on a phone, with a gui (sans many device drivers!).
because when someone goes out of the way to give us a phone with mainline and a qwerty physical keyboard like we have been asking for ages, nobody buys and they go bankrupt?
The Key2 does not run a mainline kernel, and the bootloader is locked down so you cannot run your own kernel or OS. This is not the phone "we have been asking for".
A) Until your comment, I didn't even know this existed. That's a massive marketing failure.
B) Most Chinese smartphones dump all over this with the exception of the keyboard--which comes in for all sorts of grief for being crap. You had one job Blackberry ...
Essential did the same thing with the PH-1. I think Google has been trying, and with their own SoC, maybe they will finally be able to accomplish this goal.
Last time I looked, few pmos devices used libhybris. They're mostly downstream kernels with no GPU acceleration, though they're getting progressively mainlined.
Mainlined phones generally try to leverage OSS drivers where possible.
right! thanks! i forgot about the oneplus6 & it's progress!
figuring out how to get a kernel & normal environment booting seems to be one of the biggest challenges.
there is a TianoCore EDK2 porting effort underway that seems to have support on a good number of phones. who knows what works & doesn't once you are able to start running your own mainline kernel, but way cool to see over a dozen phones on this list! genuinely excited to have some 3(+) year old phones (mostly now unsupported, insecure, or about to be!) to start to get to play with!!
this could well be a flagship demonstration of what a Right to Repair can do: save a lot of devices the landfill, prove very enduringly useful to people, once they have some self-determinism with their purchases. ad astra emptor.
There's also https://www.somainline.org focusing on SDM630/660, I'm pretty sure they have Freedreno working on these SoCs, unfortunately so far pmOS isn't adopting their latest kernel work all that quickly (?)
How would a Linux phone be wrt security? I just had my iphone stolen, don't have to worry too much about data loss because it's unlikely somebody will crack into it.
I don't think that's true for Android, but I'm not sure about Linux phones.
However, the difference of course is that with a desktop especially and also with a laptop if you are actually careful with the security of your data, is that you generally turn them off when you are not using them, so that they don't sit unprotected with the encryption keys in RAM, and they are unlikely to be stolen while you are using them.
A phone, on the other hand, is probably turned on 24/7.
But really, if someone is ready to extract the storage encryption keys of your phone from its RAM, those same people will probably snatch your laptop out of your hands while you are using it and it's unlocked.
So as long as you are able to encrypt the storage of the phone with LUKS, I think you shall have nothing to worry about with most phone thieves.
OTOH, having the storage completely unencrypted I think even the regular low-level criminals may decide to snoop on your data. At least if it's an SD card that you can just pop into a computer. But then again, neither Windows nor macOS read any of the common Linux filesystems out of the box. So probably even without encryption most thieves would not get to your data unless they were specifically motivated to go for it, and in which case as mentioned they might as well snatch your laptop (or your iPhone) from out of your hands when it's booted and unlocked.
I haven't worked with their GPUs but I do work with their camera ISPs. I suspect that their reason might be that that seeing how to write software against the chip sort of gives away the secret sauce for how the chip works. I don't know if I would agree with that, but you can kind of intuit the design of chip based on its interface. How much values that provides is unclear though :/.
Also, they do charge customers for that code and it costs money to support/customize it work customer use cases. I suspect that's another part of the equation.
I'd argue that anyone who has the skills & resources to make use of the "secret sauce" to compete wouldn't be stopped by having to reverse-engineer a binary driver?
Transparency and openness are things that in-house lawyers probably attack by default. They point all imagined risks re patents and bugs, liability, reputation, and security, and they specialize in CYA arguments.
Not all lawyers are the same :). Sure, not releasing the source code exposes you to less risks. I think the main thing that these Chinese companies fear is that a competitor can produce similar products more easily if they have access to driver source code.
From a legal standpoint, I imagine you would have less liability for bugs, because you opensourced it for anyone to see and have the option to improve upon. If the company did not introduce the bugs on purpose or as a result of some really negligent behaviour, the company doesn't have to fear liability issues. Potential patent claims etc. may be filed, but you can assess that risk. Let a patent research firm do a risk assessment and tell you how much chance people would have suing you.
And all firms need to have some sort of legal liability insurance. If you can work it out with your insurance provider that you are going to opensource part of your code, you do not have to fear anything.
You could always release two different drivers, one basic opensource driver for the community. One closed source optimized driver for the company. If you are using some risky IP etc. keep it in the closed source driver.
I thought they mostly open-sourced the GPU driver for Linux? I interpret it as a way to compete against(proprietary) CUDA dominance, but maybe that is wrong?
Yeah, and their main reason for some proprietary drivers existing is usually 3rd-party proprietary dependencies. E.g. they open sourced AMDVLK by starting with the closed Vulkan driver and replacing the proprietary compiler dependency with LLVM.
1) I will pay you to write another driver with this functionality.
2) License the driver source code to me and I will do it.
For reasons I do not remember, they would not do either.
I ended up reversing their PIO driver and implementing a version with the functionality I needed. I was uneasy about doing this, but we never sold or distributed the work so it was probably legal. (The development was for an in-house application with just one target.)