Shhh... Haiku isn't blind anymore!

Software Native
21

That one probably means the haiku_devel package.

As an aside, I’m pretty skeptical of LLMs myself but guys, if somebody gets to make a productive use of them that helps exposing issues and document them for later development that’s a genuinely positive use of that stuff, which should be encouraged, not bashed for whatever dogmatic reason.

I for one am happy to see a proper, useful usecase for LLMs instead of the usual AI-generated video slop.

Just saying.

4 Likes
22

I searched for haiku_devel in Tracker, and this came up:

haiku_devel-r1~beta5_hrev57937_129-1-x86_64.hpkg

Does this mean I’m good to go?

23

I think so :slight_smile:

If not I’m sure somebody will let us know

24

I can read the code faster than I could read a document :slight_smile: (despite the comments being partly in Italian)

So it looks like a lot of the changes are related to “split transaction” isochronous transferts (SITD). It says this is needed for isochronous transactions in high speed mode (I did not check the EHCI spec to make sure this is accurate).

The implementation adds yet another thread to the EHCI driver to manage those. Maybe there is a way to do it by reusing the existing isochronous thread (I never understood why the EHCI driver is designed with so many threads, but I also never read the code in detail).

Other changes I see:

  • Not trusting transfer->DataLength(); and instead using isochronousData->packet_descriptors[0].request_length in some cases,
  • Adding a minimum to the threshold used in computing frame index for submitting an isochronous transfer (apparently no less than 10 microframes is allowed)
  • Debug and sanity checks are added in various places
  • A missing semaphore release in an error case and a few other resource cleanups in cases of out of memory
  • Implementing “light reset” and “resume port”
  • Some reworking of AddPendingIsochronousTransfer to change how the linked list of transfers is managed. The new code looks just as confusing as the old, so I don’t know which is correct, surely this list should not be maintained by handswapping pointers?
  • Some changes apparently inspired by FreeBSd and Linux in FinishIsochornousTransfers. For Linux it at least gives a function name to reference, for FreeBSD it doesn’t.
  • It removed some hacks for low speed devices that I introduced a few years ago. I guess I should check if the gamepad that I had fixed then still works with these changes.

Overall it gives an idea what needs to be fixed. Personally I don’t feel comfortable reviewing generated code deeper than this (my interest in reviewing code is discussing it with other developers and seeing if I learn something from them, or if I can help them write better code, here it wouldn’t be the case). So that’s all there will be from me here for now.

9 Likes
25

Oh and I forgot to mention: this is all in EHCI, which is not used in modern machines (XHCI replaced it).

2 Likes
26

I’m currently on a construction site and don’t have my Haiku laptop with me. If you can be patient, I’ll prepare a zip file for you in the coming days with the alpha version of the drivers and instructions on how to test it. I’ll send you the binary so you won’t have to compile anything.

27

yes One step at a time :sweat_smile:, I’m a mechanical engineer specializing in thermodynamics

1 Like
28

Thanks. Having webcams that work on Haiku would be great!

29

Could we maybe consider having a no LLM rule for patches to Haiku? Even when ignoring the potenial breaches of software licenses that these models pose, using generated code is just a maintenance and security nightmare waiting to happen.

Also, a lot of “ai”-companies have been hostile to infrastructure of open-source projects (e.g. crawling cgit instances, generating huge costs and slowdowns for these projects) which I think we should just not support or normalize. Anubis exists for a reason.

5 Likes
30

We already have one.

8 Likes
31

Indeed, it’s on this page:

The Haiku project cannot accept contributions (e.g. code, documentation, translations, etc.) which are under ambiguous or incompatible licenses. (This includes most content produced with the use of LLMs.)

4 Likes
32

As far as I know, the XHCI driver should already have most of what’s needed for isochronous support. (Obviously it already works with USB 1.0 both input and output for the USB Audio driver.) There may be some missing parts for USB 2, but at most I expect that’ll be some size or timing computations, and not anything more complicated than that.

3 Likes
33

I wanted to give a little update: I’m testing two webcams, one integrated into the laptop (an old Sony Vaio from 2010) and one external, much newer webcam. I am running the tests on USB 2.0 ports (I know they are old, but the keyboard and touchpad don’t work on my new laptop). Codycam has been running since this morning without any issues.

photo_5888754253264784434_y
photo_5888754253264784434_y1024×768 176 KB

With BubiCam, I managed to get a constant video stream with USB 2.0 at a resolution of 1280x720 by modifying the EHCI bus. Unfortunately, I have no way to test the XHCI modifications made to get it working on USB 3.0.

photo_5886502453451099089_y
photo_5886502453451099089_y888×768 133 KB

All this work was done with the massive use of Claude Code. Therefore, I am perfectly aware that it will NEVER be integrated into the Haiku codebase, but I think it could still be useful for many people who love Haiku.

As soon as I finish solving a bug with YUY2 and the microphone, I will share everything, even though you can find all the sources and binaries on BeShare.

12 Likes
34

Wouldn’t the following steps be manualy cleaning/formating/commenting the code so it becomes humanly managable, and therefore integratable to Haiku code base?

Or is it too much of a mess?

1 Like
35

The code is already commented according to the project directives. The problem is the project rules that prohibit adding AI-written code to the repository. I don’t think they’re wrong, they’re choices, but I think it’s wrong to be a ‘Taliban’ about code written with AI. So this project will simply be external :slight_smile:

4 Likes
36

So from what I understand, somebody could “manualy” diff the changes and import them back into Haiku proper?

37

Sure, it’s not difficult

1 Like
38

If one copies AI changes and imports them as his own then he is still violating AI policy…A more legal approach is to use AI changes to create a proposed working version quickly, test it and then share only the conclusion e.g “in order to have a Haiku version that boots on Arm 64 you need to modify that file and add code that does this” This kind of description can probably save time to people knowing the code base in order to proceed in areas that they are stuck or slow. This makes AI a kind of “untrusted but extremely quick developer” …Its approach-suggestions may be rejected anyway by a human developer.

2 Likes
39

As far as the technical side is concerned, if you can explain the relevant parts of the code to the core devs and answer questions about it or make requested changes, the code might get accepted (I may be wrong on this). But of course the legal side with all the uncertainties around AI generated code will still stand in the way and I currently don’t see any solution to this.

Anyway, congratulations and thanks for getting webcams to work on Haiku. Even if it doesn’t get integrated into the OS, the software is still out there for everyone to use.

Oh yes, and it would be great if you could do us all a favor and stop calling everybody with different views on AI a “Taliban”. That does not encourage a civilized discussion. You could use the word “fundamentalist” or if that’s not enough you might use the word “Stallman” :wink:

4 Likes
40

LooooooL :slight_smile: I had the opportunity to meet Stallman in Padua many years ago, and he was quite the Taliban :sweat_smile::rofl:

3 Likes