cacao VS evdi

This is really specific, but for this point in the article:

> There’s a long guide on Embedding a Command-Line Tool in a Sandboxed App, so I followed that, and then slowly, painfully, factored Xcode out of it, so that I wouldn’t have to figure out how to get a 10GB Xcode install onto the CI machine (remember, you need to be signed in to an Apple ID to download Xcode, and there’s no way to do it from the command-line).

You could actually solve this with Rust and no Xcode whatsoever. cacao [1] and cargo-bundle [2] will produce an app bundle you could sign/notarize/distribute without needing to ever open Xcode.

[1] https://github.com/ryanmcgrath/cacao

I've had basic animation support in cacao for about a year now, but I don't think anybody even realizes it.

But I will reiterate what I say on many posts like these, which is that it would be even cooler if we could stop having a million projects reinvent this wheel - and I say this as someone who wrote a large Rust library that is backed by ObjC. madsmtm has an ongoing effort to put together a best in class ObjC Rust wrapper, which would be great to see even more support for.

MacOS; I have to call the AppKit API. I can use a library like this which offers Rust bindings for AppKit - otherwise I can write my own maybe?

Yes, you can: https://github.com/ryanmcgrath/cacao

git clone https://github.com/DisplayLink/evdi.git

So I'm currently on Ubuntu 22.10 with Mesa and asahi-edge kernel. You need both to allow using primary GPU as source output. I'm using evdi 1.13.1 with the correction to set the module to the 1.12.0 to run the script displaylink from Synaptics for Ubuntu.

The RPM version never worked for me. It's only useful for getting the services installed. After that clone the repo from https://github.com/DisplayLink/evdi and change to the devel branch. Run make and sudo make install. If you use SecureBoot you also need to sign the resulting evdi.ko with your key. After that restart displaylink.service or reboot and it should work. At least it did for me. I's been a while since I had to use it.

Uninstallation steps complete. darren@pop-os:~/displaylinkfix$ ./displaylink-driver-5.6.1-59.184.run --noexec --keep Creating directory displaylink-driver-5.6.1-59.184 Verifying archive integrity... 100% MD5 checksums are OK. All good. Uncompressing DisplayLink Linux Driver 5.6.1-59.184 100% darren@pop-os:~/displaylinkfix$ cd ./displaylink-driver-5.6.1-59.184 darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$ curl -L https://github.com/DisplayLink/evdi/archive/refs/heads/devel.tar.gz -o evdi.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 80603 0 80603 0 0 179k 0 --:--:-- --:--:-- --:--:-- 179k darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$ nano darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$ nano evdi.tar.gz darren@pop-os:~/displaylinkfix/displaylink-driver-5.6.1-59.184$

I'm afraid this might be a hardware issue, maybe with the cable. I don't have a second cable to swap out unfortunately. A new one won't be here until Saturday. And it seems like a hell of a coincidence for the cable to fail when there's other issues reported within the last few days that seem very similar.

https://github.com/DisplayLink/evdi states

Theres a bug in the 6.2 kernel right now with at least the evdi package (dont know about evdi-git) but can be fixed with a patch. Pr for it is already open but yet to be merged https://github.com/DisplayLink/evdi/pull/401