lets talk about the phasing out of haluim

oldbutndy

@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.

arubislander

@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

@Moem 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 ....all of us have been using AI and not aware for the last 20 years

developerbayman

@arubislander yes for sure should be open source im even thinking as its scanning and developing the driver the user could watch it save the output raw ....should be a cool tech tool that eliminates this problem ...very transparent

developerbayman

@arubislander its to my understanding they past "right to repair " basically everywhere? ...the U.S and the U.K?? .....my logic is once i buy the device its mine including any gpu or hardware included ....the fact companies wont come off drivers is nothing more than a way to keep trying to extort money from you ....and actually would violate right to repair ....i would argue this in court because once you backwards engineer anything without even looking at the proprietary drivers ....its no longer their ip ...also there is a few "legal" approaches to this ...also i would cite precedence .. 1. NEC Corp. v. Intel Corp. (1989/1990)

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.

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.

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

@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 ?

oldbutndy

@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

@oldbutndy not look at any code but actually test the hardware ..and i dont im sure it would basically be a nuts ...ill toy with it a little later i think lol maybe ill try my phone for a laugh not really a issue on it being unlocked and already running UT

arubislander

@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.

oldbutndy

@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 ?