Touchscreen state gets forgotten after restart

[thoraine]

Hello, I hate the touchscreen feature on my Xiaomi Book Pro 14 2026 so I previously disabled it using the Device Manager. However your app now controls it and seemingly turns it back on after every reboot. Can you fix it so that it remembers the state?

[Oksion]

Thanks for reporting this — and sorry for the annoyance. You are very likely right that it is us doing it, and I want to explain what I found before I change anything, because the fix depends on which of two things is happening on your machine.

The honest problem

XiControl has no concept of "off permanently". Its only notion of "off" is off until the next reboot.

The normal way it disables a device does not survive a restart by design. When that path fails, it falls back to the same persistent disable that Device Manager uses — and because that does survive a restart, XiControl records a flag and re-enables the device on the next start, so it does not leave your hardware dead forever.

That logic is reasonable on its own, but it has no idea that you might want the device off permanently. So "remember the state" is not a small fix — it is a missing idea in the app, and I am adding it.

The bug that probably makes it repeat

Reading the code again with your report in hand, I found something worse than the design gap.

After re-enabling, XiControl waits up to 1.5 seconds for the device to report itself as enabled, and only clears the flag if it sees that. PnP operations are asynchronous, and re-enabling a persistently disabled device can take longer than that — especially when it falls through to a full bus re-enumeration.

If it takes longer, the device does come back on, but XiControl records the attempt as a failure and never clears the flag. From then on it re-enables the touchscreen on every boot — including after you disable it yourself in Device Manager, which would otherwise be none of our business.

That matches your description exactly:

1. you turn it off (through XiControl at some point),
2. reboot, we turn it back on, but mis-record the result,
3. you give up and use Device Manager,
4. every reboot after that, we turn it on again — because the flag is stuck.

Two things I would like from you

Both are read-only, and they tell me whether the stuck flag is really what is happening:

1. log.txt from %APPDATA%\XiControl\ (or next to the exe in portable mode; the exact path is on the About tab). I am looking for the line Touchscreen: включаю после перезагрузки. The key question is whether it appears on several different boots, or only once — several means the flag is stuck and this is our bug; once means something else re-enables the device and I should look elsewhere.
2. The value of TouchscreenPersistOff in config.json, same folder.

Feel free to trim the log to the touchscreen lines if you would rather not post the whole thing.

A workaround for right now

Turning the touchscreen feature off in Settings → Features will not help — I checked, and the boot-time re-enable does not consult that switch. That is its own bug and it is on the fix list.

What does work today:

1. Fully exit XiControl (right-click the tray icon → Exit).
2. Open config.json and set "TouchscreenPersistOff": false.
3. Save, then disable the touchscreen in Device Manager.
4. Start XiControl again.

With the flag cleared, XiControl has no reason to touch the device, and your Device Manager setting should stick.

What I am changing

• Separate "the user wants this off" from "we disabled it and owe a cleanup" — they are different things and the code currently conflates them.
• Never re-enable a device XiControl did not disable itself.
• Stop treating a slow-but-successful enable as a permanent failure.
• Make the boot-time restore respect the feature switch.
• Same fix for the touchpad, which has identical logic and the same bug — nobody has hit it yet.

Thanks again. This one is a real design hole, not a small oversight, and it took your report to make it visible.