@Fla said:

I think Waydroid is tight to Halium too, isn't it?

I don't think this is inevitably the case. Else how would it work on regular desktop Linux? Also I think I got it running on the PinePhone. It ran terribly slow, as everything else on that hardware, but it did run.

@oldbutndy said:

But, it seems this would end up not reducing the huge number of variations for all the different phone models.

Am I missing something here ?

No, you are on to soimething. People forget that ARM hardware in general and phone hardware in particular is totally not standardized. So to get all the drivers for all that hardware upstreamed would be a huge endeavor. One, frankly that I am not at all convinced that AI is capable of taking on. And even if and when, new hardware keeps coming out with each new generation of devices, so you'd have to practically start from scratch each time.

We saw how just the jump from Pinephone to PinePhone Pro brought in such fundamentally different hardware that the Pro never really caught up, software wise, with the original device.

What makes 'mainline' kernels viable on x86 / x64 server and desktop is the high degree of standardization of the hardware in that area.

@arubislander said:
The thing is that any new support for hardware is likely to land in newer version of the kernel. Halium ports are tied to a specific version of the kernel for ABI compatibility with the drivers the device vendor provides. And backporting those new drivers to the older kernels would probably be more work than it's worth.

Ahhh. Excellent point. Thank you.

so, for @developerbayman style AI assisted concept to work, either every single hardware driver would have to be created & built into modern kernel (for each phone or all phones), or, to use halium layer for the difficult parts, would mean custom modifying every kernel, for each old device, to use the newly created drivers and still talk to halium for some.

So, AI could make this possible, by saving time in some areas.

But, it seems this would end up not reducing the huge number of variations for all the different phone models.

Am I missing something here ?

@oldbutndy said:

Also, is it possible to retain halium layer for modem-radio and other components for which there is no no kernel driver, but put simple things (I assume turning flashlight LED on & off & PWM for dimming would be easy) into kernel ?
Is that how it already IS being handled ? or does halium translate everything ?

The thing is that any new support for hardware is likely to land in newer version of the kernel. Halium ports are tied to a specific version of the kernel for ABI compatibility with the drivers the device vendor provides. And backporting those new drivers to the older kernels would probably be more work than it's worth.

@developerbayman said:
... AI isnt always like a LLM like chatgpt you can have a very basic small ML program that does one thing very intelligently between a few options ...it chooses or does one or a few things based on the input ...

I understand that the various AI's have differences, and that the frequent crap answers I get from Google quick response and 'dive deeper' (Gemini 3.2 Pro), might not be the same as using Claude 4.n specifically to code.
I recently tried Claude for C++ coding for the first time ever, and while I was impressed, and it helped fix mistakes I made, I also helped fix mistakes Claude made. The only way I was able to do that was by having every bit of the code available to study (and I had told it the concept of the project, knowing exactly what I wanted, and had created similar thing 5 years ago, using Arduino - so I had very specific related knowledge).

So, I think your idea that AI could look at all code & reverse engineer seems like it could speed up the process, but I think you still need highly experienced coders with specialized background for each hardware device you are creating driver for, to review that code. Your AI might save them time.

Anyone have any guesses on how long it would take for a driver (pick one), with and without AI help ?
Is it hundreds or thousands of hours (for the difficult parts, like modem-radio) ?
I am asking because I have no idea ?
Also, is it possible to retain halium layer for modem-radio and other components for which there is no no kernel driver, but put simple things (I assume turning flashlight LED on & off & PWM for dimming would be easy) into kernel ?
Is that how it already IS being handled ? or does halium translate everything ?

@developerbayman said:
... its to my understanding they past "right to repair " basically everywhere? ...the U.S and the U.K?? ....

I thought, in USA, a few states have passed a few laws regarding 'Right to repair'. Articles I read in recent years pointed out limitations and weaknesses in the laws. Maybe there are newer better laws. If you know of them, please post a link or a search term, specifically for those right to repair laws.
The cases you mentioned are good, but that still could mean ending up in court, to PROVE that you did a 'clean' or 'isolated' reverse engineer process.
Whatever process the Linux team that developed the Nvidia GPU driver followed would be a very relevant example, right ?

This is the landmark case that officially validated the "Clean Room" defense in a U.S. court.

The Conflict: Intel accused NEC of copying the microcode for the 8086 processor to create their own V20 chips.

The Strategy: NEC hired an independent engineer who had never seen Intel’s code. They gave him a specification of what the microcode needed to do (the functional requirements). He then wrote his own version from scratch.

The Ruling: The judge compared the "Clean Room" code to Intel’s code. He found that while they were similar, the similarities were due to functional constraints (there were only so many ways to make the hardware work) rather than copying. This proved that a person could arrive at the same result independently, effectively defeating the copyright claim.

2. Sega Enterprises Ltd. v. Accolade, Inc. (1992)

This case expanded the right to reverse engineer for the purpose of interoperability.

The Conflict: Accolade wanted to make games for the Sega Genesis without paying licensing fees. They disassembled Sega’s code to understand how the console "talked" to the cartridges.

The Ruling: The court ruled that disassembling code to understand its "unprotected functional elements" is Fair Use, provided there is no other way to gain that information for interoperability. This supports your right to scan hardware to understand how a driver needs to behave.

3. Computer Associates International, Inc. v. Altai, Inc. (1992)

This case established the "Abstraction-Filtration-Comparison" test, which is still used today to see if a program is a "copy."

The Strategy: After realizing an employee had copied code from a competitor, Altai performed a "Clean Room" rewrite. They used a fresh team of programmers who only had access to the functional specs, not the infringing code.

The Ruling: The court found the new version did not infringe. They ruled that elements of a program dictated by efficiency or external factors (like hardware compatibility) are not protected by copyright.

@oldbutndy said:

As long as everything it generated was open source, so it could be reviewed.
Otherwise, unsafe.

The problem is, that there is no way to tell. We don't know what the AI was trained on. So we can't know if what it reproduces is in violation of any licenses, proprietary or otherwise.

@developerbayman said:
...utilize AI to backwards engineer hardware drivers...

As long as everything it generated was open source, so it could be reviewed.
Otherwise, unsafe.

@developerbayman said:

...well AI anyway and on the fly ideally the user shouldnt even know its happening

This would make me dump whatever it was, hard and fast. People should always, always be aware that a process uses AI, so they can make a choice.

@grenudi said:
... Dipping my hands into those projects ... and finally get working on perfecting the actual day to day use cases ...

Hmmm - no such thing as perfecting, just iterating and releasing ... (hahaha)

Embedded - Fun stuff, like my Fridge temp graph: Arduino, now ESP32, + 3.5" LCD, because I tried to find & buy one & nobody made what I wanted.
I wanted Linux native on my phone, but my brains coding limit is ESP32 (maybe better in future with AI help...).
Searched for years !
Fortunately, the UT devs finally got it to a point I can use it !

@developerbayman said:

... my own custom AI ...

? LLM style, or something else ?