[Bug]: MUI screen is backward
Category
Other
Hardware
T-Deck
Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?
- [x] Meshtastic UI aka MUI colorTFT
- [ ] InkHUD ePaper
- [ ] OLED slide UI on any display
Firmware Version
2.6.11 xxxxxxxxx
Description
You discontinued the screen calibration and now the touch screen is backward. To select something on the left you have touch the right side of the screen. You need to add the screen calibration option back the the menu. Thank you
Relevant log output
Just do a factory reset, except your screen is reversely assembled.
No factory did not work. Some how one of the versions flipped my screen about 6 months ago and without the calibration it will not work right. If I remember correctly the version was for a T Deck Plus but was listed as being for the T Deck.
Factory reset does not fix it.
On Thu, Jun 12, 2025 at 6:50 PM Tom Fifield @.***> wrote:
Closed #7021 https://github.com/meshtastic/firmware/issues/7021 as completed.
— Reply to this email directly, view it on GitHub https://github.com/meshtastic/firmware/issues/7021#event-18125468052, or unsubscribe https://github.com/notifications/unsubscribe-auth/BLDNRZLXUDUBCHZJAWCCCX33DIU6TAVCNFSM6AAAAAB7D7ORAKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJYGEZDKNBWHAYDKMQ . You are receiving this because you authored the thread.Message ID: @.***>
Factory reset does not fix it.
Ask Lilygo for help, they shall provide you a command sequence to undo the changes done by running their T-Deck-Plus unittest.bin on T-Deck.
Factory reset does not fix it.
Ask Lilygo for help, they shall provide you a command sequence to undo the changes done by running their T-Deck-Plus unittest.bin on T-Deck.
It’s incredibly disappointing and frustrating that the screen calibration feature was removed entirely. It previously offered a simple and effective way to account for hardware differences, especially since not all units are assembled the same. Directing users to the hardware vendor to fix something that was broken by firmware feels like punting the problem downstream.
Please consider restoring the calibration option, or at least exposing a config flag or setting to reverse the touch input manually. Relying on vendor-specific binaries to resolve this isn’t a reasonable long-term solution and is very hostile to users.
The change was requested by the hardware vendor itself, see PR #6969 because half of their T-Deck Plus devices that came from their factory had issues with the touch screen when running the meshtastic firmware. The changes made solves almost all touch issues for thousands of devices.
Also, the firmware that bricked your T-Deck came from the hardware vendor itself, so it's more than reasonable to direct you to the hardware vendor. They stated clearly not to run the T-Deck Plus unittest.bin on the older T-Deck enclosed by dozens of exclamation marks which you ignored.
If you are able (and willing) to compile the meshtastic firmware by yourself which takes only a few minutes you can fix this issue for your device by reversing just a single line of code. It's as simple as that.
Well in my place that is not correct. The firmware was listed as for the T Deck and not the T Deck Plus. At one time I could have done what you are talking about doing but that was 25+ years ago. I have not kept up so it has run off and left me. I also get this, Although you appear to have the correct authorization credentials, the 'meshtastic' organization has enabled OAuth App access restrictions, meaning that data access to third-parties is limited. For more information on these restrictions, including how to enable this app, visit https://docs.github.com/articles/restricting-access-to-your-organization-s-data/.
On Wed, Jun 25, 2025 at 11:51 PM Manuel @.***> wrote:
mverch67 left a comment (meshtastic/firmware#7021) https://github.com/meshtastic/firmware/issues/7021#issuecomment-3007366342
The change was requested by the hardware vendor itself, see PR #6969 https://github.com/meshtastic/firmware/issues/6969 because half of their T-Deck Plus devices that came from their factory had issues with the touch screen when running the meshtastic firmware. The changes made solves almost all touch issues for thousands of devices.
Also, the firmware that bricked your T-Deck came from the hardware vendor itself, so it's more than reasonable to direct you to the hardware vendor. They stated clearly not to run the T-Deck Plus unittest.bin on the older T-Deck enclosed by dozens of exclamation marks which you ignored.
If you are able (and willing) to compile the meshtastic firmware by yourself which takes only a few minutes you can fix this issue for your device by reversing just a single line of code. It's as simple as that.
— Reply to this email directly, view it on GitHub https://github.com/meshtastic/firmware/issues/7021#issuecomment-3007366342, or unsubscribe https://github.com/notifications/unsubscribe-auth/BLDNRZJDANDNXUR4NQ7PLEL3FOJ6NAVCNFSM6AAAAAB7D7ORAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBXGM3DMMZUGI . You are receiving this because you authored the thread.Message ID: @.***>
The change was requested by the hardware vendor itself, see PR #6969 because half of their T-Deck Plus devices that came from their factory had issues with the touch screen when running the meshtastic firmware. The changes made solves almost all touch issues for thousands of devices.
Also, the firmware that bricked your T-Deck came from the hardware vendor itself, so it's more than reasonable to direct you to the hardware vendor. They stated clearly not to run the T-Deck Plus unittest.bin on the older T-Deck enclosed by dozens of exclamation marks which you ignored.
If you are able (and willing) to compile the meshtastic firmware by yourself which takes only a few minutes you can fix this issue for your device by reversing just a single line of code. It's as simple as that.
I need to be clear here: I didn’t flash the wrong firmware or run some random vendor tool. I used the official web flasher, and it gave me firmware that (allegedly) broke the touchscreen. If that tool served the wrong image, that's not the user's fault.
It's pretty frustrating to be told this is my fault, especially when the calibration feature (which again, previously made this a non-issue) was removed with no alternative. Telling users to compile their own firmware or go chase a vendor for a fix isn't just unhelpful, it's actively hostile. Most folks aren't in this repo because they want to build firmware. They're here because they just want their device to work.
Restoring calibration, or at the very least exposing a simple config flag to reverse touch input, would resolve this for a lot of users without putting the burden on them to clean up a mess they didn't create.
Well if it is "It's as simple as that." why doesn't someone post how to do that so thousands of people don't have to go to Lilygo and ask how to do it?
So I guess it is not that simple.
So it looks like it is closed because nobody can give an answer. Great why did I ever waste my time trying to get an answer that a lot of people would benefit in knowing form a bunch of people that they are better than everybody else just because they know a tiny bit of what they could know about the real world.
So it looks like it is closed because nobody can give an answer. Great why did I ever waste my time trying to get an answer that a lot of people would benefit in knowing form a bunch of people that they are better than everybody else just because they know a tiny bit of what they could know about the real world.
Yeah, I took a swing at this a couple weeks ago and despite changing more than one line, I can't get the calibration feature to be available in the mUI at all.
It's quite telling that no one has shown up to just give a set of instructions to make this work. I'll see if I can find some more time to figure it out next week but, yeah. I'm about ready to just sell my T-Deck since the support here is awful.
I took a swing at this a couple weeks ago and despite changing more than one line
Well, if you looked at the PR code (see link above) to fix the T-Deck touch issue for LILYGO then you'd see it is in fact only a single line of code that is to change to revert it (line 70).
Great now explain how to do that and reload it into your system.
You have all the programs to do that and where and how to load it nobody else does or we would already done it.
Well, if you looked at the PR code (see link above) to fix the T-Deck touch issue for LILYGO then you'd see it is in fact only a single line of code that is to change to revert it (line 70).
Thank you for pointing out the line, though I'd ask that we dial back the implication that I didn't look.
To be clear, the only thing linked in this issue thread is another issue (#6969), which itself references multiple pull requests (like meshtastic/device-ui#149 and #6988). So for the average Meshtastic user (most of whom aren't deep in GitHub PRs) figuring out which "one line" is relevant isn't exactly trivial. Even as someone somewhat familiar with this codebase and quite familiar with embedded dev in general, it took more than a passing glance to trace through.
Even then, the commit you linked changes multiple lines. So unless someone already knows the context, they're still left guessing which line matters, and if they guess wrong twice, that's a 75%+ chance of hitting a dead end. That's a pretty rough UX just to undo a regression introduced upstream.
And here's the bigger issue: I did revert that line. It didn't fix the problem. So either something else has changed since then, or it's not the silver bullet it's being presented as.
At the end of the day, this isn't about whether it's one line or ten... it's about how the project responds when users are left with broken hardware and no clear, supported path to fix it. Telling people to just figure it out or go compile it themselves, with no runtime toggle or config, is frustrating--and when it's delivered with condescension, it burns goodwill fast.
If the project wants to be accessible to more than just firmware devs, it might be worth considering that.
And here's the bigger issue: I did revert that line. It didn't fix the problem. So either something else has changed since then, or it's not the silver bullet it's being presented as.
It gives you back the possibility to perform a calibration as you requested!
There is no known fix for any other touch related issues. The only tool provided by LilyGo is the unittest.bin (which must not be run on a plain T-Deck).
Again this PR change was requested by LilyGo to help thousands of their customers who purchase a new T-Deck Plus, because LilyGo does not run the unittest.bin at their factory and so 50% of them are facing the touch issue (all documented in the links above). Then, there is a handful of people (like flyfinger) who flashed malicious firmware which was uploaded to 3rd party storage and bricked their device by doing so and which turned it into a DIY device because nobody knows what malicious code they were executing and how to revert it, see e.g. this public conversation:
As I'm doing all this work voluntarily in my spare time and invested already thousands of hours I'm not willing to spent extra effort for a handful of people who bricked their devices and are talking and demanding in an aggressive way without giving any kind of appreciation for the software that I provide totally for free of charge as open source which of course can be changed and compiled by anybody who studies the official meshtastic documentation.
@mverch67, I want to start by saying I really do appreciate the time and effort you’ve put into Meshtastic. As an open source developer myself, I understand how much of a personal investment this kind of work is, and I don’t take that for granted.
That said, I hope you’ll hear this in the spirit it’s intended: this situation has been confusing and frustrating, not because anyone expects instant fixes, but because the change removed something that previously worked, and users haven’t been given a clear path to recover. For folks who aren’t compiling their own firmware (which, realistically, is most users), that puts them in a really tough spot. I think that’s where some of the frustration you’re seeing is coming from.
I’m not saying you need to drop everything and fix it, but I do think we need to stop framing this as “users did this to themselves.” As I’ve said, I’ve never run unittest.bin on my device, so there’s at least one class of users (probably more) who ended up in this state without any deliberate action. In any case, it doesn’t help to dismiss them.
On the technical side, I just recompiled the firmware with the CUSTOM_TOUCH_DRIVER flag removed and flashed it to my device. This time, the calibration menu does return. I’m not sure what changed between now and my previous attempt (or if I simply messed something up), but it appears to be working now.
For the sake of others who might want to do this without VS Code, here's a brief outline (largely based on the official docs:
- Make sure PlatformIO is installed.
- Clone firmware repo:
git clone --recurse-submodules https://github.com/meshtastic/firmware cd firmware - Edit
variants/esp32s3/t-deck/platformio.iniand remove this line:-D CUSTOM_TOUCH_DRIVERYou could also comment it out by adding a;at the start of the line. - Build the
t-deck-tftvariant:./bin/build-esp32.sh t-deck-tft - Backup your device config!
- Flash using the script in the release folder (your file and port may vary):
cd release ./device-update.sh -f firmware-t-deck-tft-2.7.3.4f281ad22-update.bin -p /dev/ttyACM0
Thanks again for everything you’re doing, @mverch67. And I’m sorry if I came across as aggressive or unappreciative earlier; that wasn’t my intent, but I recognize how it could be read that way.
I’ll try to put together a doc PR or some further notes this week to help others in the same spot.
I tried to do what you posted and I could not follow it. For me there does not seem to be enough information. Now my first computer was a Commodore Vic 20 and I have been working with computers since 1966 so if I can't follow it I doubt many can. Now I have not been active active in about the last 10-12 years and the technology has run off and left me that I understand. At one time I knew 6 programming languages none being C++ or Python so those are both Greek to me. You might need to dumb it down so this old man can understand it.
@NeilHanlon is it possible to share the firmware you compiled also?
@NeilHanlon is it possible to share the firmware you compiled also?
Yeah, I can do this.. Just, it can't come with any expectation of support. It seems some people may have gotten themselves into this using some random firmware in the first place, so I don't want to continue a pattern of random github firmware for people :)
I'll put together a .zip that can be uploaded to the web flasher, which will make the process more foolproof.
Did you get a chance to work on that .zip?
Ok looks like this is closed and we still don't have a solution. Let me ask another question. How do I reinstall the factory software and don't say reset because that does not work. Showing me a picture of something and saying go change this line and not telling how to get it into the device is not working. I can change it 1000 times on my computer but getting it into the T Deck in the right place is what I am asking.