Page 1 of 1
RNS-E in Audi A2
Posted: Tue Nov 04, 2025 2:13 pm
by korni92
Hi
I am using Hudiy on a RNS-E and made some scripts to control Hudiy via the RNS-E button. In TV mode some buttons are published to the CAN. I also use certain messages and Hudiy API to switch between Day/Night mode or to shutdown the Pi.
At the moment I am working on showing data from the API fror music, naviagation and phone in the cluster of the car.
I have some trouble with the DDP protocol. I can clear the whole middle section of the screen, but on the middle section I can only write to lower half. No matter what values I write, I always end up on the lower half. Maybe someone has experinced this before.
Re: RNS-E in Audi A2
Posted: Tue Nov 04, 2025 5:35 pm
by a8ksh4
That's rad. You could show all kinds of useful stats there.
Re: RNS-E in Audi A2
Posted: Wed Nov 05, 2025 2:04 pm
by korni92
It was a positioning problem.
Re: RNS-E in Audi A2
Posted: Thu Nov 06, 2025 12:44 pm
by korni92
Re: RNS-E in Audi A2
Posted: Sat Nov 22, 2025 2:24 pm
by Hiphouser
Do you have a detailed picture of you custom pi box?
I have found your 3d print Files.
But what composent have you used?
Nice project!
Re: RNS-E in Audi A2
Posted: Thu Nov 27, 2025 1:36 pm
by korni92
My components:
- Pi 4
- Hifiberry DAC+
- CarPiHat
- The PCB from a cheap Ali Express composite RGBS RNS 810 camera converter.
Re: RNS-E in Audi A2
Posted: Thu Nov 27, 2025 3:36 pm
by hudiy
Hello korni92,
Thank you for your feedback on Instagram. To follow up, here is a brief overview of how key events are handled in Hudiy:
Regular key events are delivered by labwc (window compositor in Raspberry Pi OS) through the Wayland protocol (communication mechanism between window compositor and UI app). They are received by Hudiy in the UI thread and then, depending on the current input focus, they are either forwarded asynchronously to Android Auto / CarPlay or handled by the Hudiy UI (in the UI thread).
In case of the API, the difference is that events are delivered to the UI thread through the TCP/WebSocket layer, and from that point on the processing path is exactly the same as for physical keyboard events.
In theory, injecting key events via the API should actually be faster, because there are fewer layers for the event to pass through before reaching the UI thread:
Keyboard path:
hardware -> driver (kernel) -> libinput -> labwc -> Wayland protocol -> Hudiy (UI thread)
API path:
API client -> TCP stack (kernel) -> Hudiy (UI thread)
All connections to the API endpoints (TCP/WebSocket) are handled asynchronously using epoll, which is a high-efficiency I/O dispatching mechanism in the Linux kernel.
WebSocket itself (if used instead of plain TCP) doesn’t introduce significant overhead - it’s just an additional lightweight layer on top of raw TCP/IP (similar to SSL).
If you can share the code you use to inject key events via the API, we can run it on our side and help analyze what the possible bottleneck might be.
Re: RNS-E in Audi A2
Posted: Fri Dec 05, 2025 11:32 pm
by korni92
hudiy wrote: Thu Nov 27, 2025 3:36 pm
Hello korni92,
Thank you for your feedback on Instagram. To follow up, here is a brief overview of how key events are handled in Hudiy:
Regular key events are delivered by labwc (window compositor in Raspberry Pi OS) through the Wayland protocol (communication mechanism between window compositor and UI app). They are received by Hudiy in the UI thread and then, depending on the current input focus, they are either forwarded asynchronously to Android Auto / CarPlay or handled by the Hudiy UI (in the UI thread).
In case of the API, the difference is that events are delivered to the UI thread through the TCP/WebSocket layer, and from that point on the processing path is exactly the same as for physical keyboard events.
In theory, injecting key events via the API should actually be faster, because there are fewer layers for the event to pass through before reaching the UI thread:
Keyboard path:
hardware -> driver (kernel) -> libinput -> labwc -> Wayland protocol -> Hudiy (UI thread)
API path:
API client -> TCP stack (kernel) -> Hudiy (UI thread)
All connections to the API endpoints (TCP/WebSocket) are handled asynchronously using epoll, which is a high-efficiency I/O dispatching mechanism in the Linux kernel.
WebSocket itself (if used instead of plain TCP) doesn’t introduce significant overhead - it’s just an additional lightweight layer on top of raw TCP/IP (similar to SSL).
If you can share the code you use to inject key events via the API, we can run it on our side and help analyze what the possible bottleneck might be.
I will have a look, you changed a lot on the API of Hudiy, which is awesome. No virtual environment, for example. It's so much faster and reliable than it was before.
Changing tracks, before there was noticeable delay in delivery the new information to show it on the cluster. Now it's so fast, I needed to add a delay on for the white DIS clusters not to overwhelm the processor of the old dash.
I dumped the code of the control via API, because it felt so much slower, especially when scrolling through playlists. There was a noticeable delay and sometimes it felt that it missed some scrolls, which I haven't noticed with uniput.
Re: RNS-E in Audi A2
Posted: Mon Feb 09, 2026 1:47 am
by korni92
It started small, but it escalated totally. In the beginning I wanted to have just Android Auto on the RNS-E. Later also more car integration with day/night mode and as the cherry on top ... DiS integration.
The system works fine and hudiy is awesome. Maybe some theming would be cool in the future, to make the menu look like the actual RNS-E menu structure.
In the process I got so much positive response, that I even started to extend this project, far above my own needs. I found out more and more about the protocol to send data to different types of the screen and got help from Vlad with sending bitmap and handling the color cluster screen.
All different clusters require some different handling. So I started to get a few to improve everything to be as flexible as possible and to wotk in as many Audis as possible that came with the RNS-E
Still not finished, I need to make more graphics for icons, navigation arrows and finishing the car info menu.
Also the physical integration into the car was important. I wanted to have a proper mounting spot and housing, so everything is secure, easy to reach and to maintain.
