Hello everyone, I’ve had my i5 FW12 for a little over a month, now. I purchased the official stylus right alongside with it, as I wanted to use the touch functionality regularly. Tapping GUI elements is fine, but the other day I installed Microsoft Journal and found out that writing anything in cursive is straight up impossibile. The touch input lags and stops mid-word, and then resumes as you keep on writing. The systems tries guessing what your input was while it was lagging, resulting in random broken lines, skipped strokes and wonky letters. It happens in any app I’ve tried: OneNote, Journal, Paint, Photoshop. Taking notes on this device is out of the question, it’s way too frustrating. Does anybody have the same issue?
I’ve used Windows and Linux and haven’t had this issue, though I don’t remember for sure if I used any of those apps. I feel like I probably tried OneNote and Paint, but I can’t remember 100%. I don’t currently have Windows on my FW 12, so I can’t try those apps right now.
Maybe there’s an issue with your stylus where it requires too much pressure to be detected or something. If you press a bit harder, will it stop dropping out?
The thing is, it happens with my finger as well. I’ll try and record another video to better show the issue, it’s kinda hard to explain. I started noticing this behavior in a couple of journaling apps, but it actually happens system wide. If I start dragging and shaking a window, even if the movement with my finger (or stylus) is uninterrupted, I can see said window stopping and being dragged again every 2/3 seconds. It feels like the computer is trying to catch up. No spikes in the Task Manager are visible, though.
I must say, I cannot figure out a fix and it’s getting on my nerves. I don’t have much time to deal with this. I have a pending ticket with the Customer Care which does not seem to be going anywhere (as in, I’m asked to perform generic troubleshooting procedures that do not seem related to the issue).
I’m lost, but the computer is unusable in its current state.
UPDATE: I just noticed that one the of buttons on my Framework pen maps to the eraser tool in Photoshop. If I keep the button pressed, my brush is supposed to act as an eraser.
I can’t even do that. I works as the eraser for a bit, and then - without depressing the button - it lags and switch to the brush again. It is almost as if my touch panel switches itself off every few seconds. WTH
Is it consistent across apps - sounds like yes at least in Windows.
Is it consistent with the stylus in the different modes (USI? / MPP?)
Is it consistent across different OSes - if you boot into a live linux do you have the same issue?
Is it consistent with different styluses (styli?) - assuming you have a different one to try out.
Best of luck getting it working. I have a 12” i3 with the Framework stylus and it works well enough for me when I am taking notes in joplin via waydroid and gboard (?) handwriting recognition. My cursive is pretty terrible so I am writing in print, but I haven’t noticed any lags.
I know you said this lag happens even when you use your finger to drag a window about. What about when dragging something with the touchpad or a mouse? What about drawing with the touchpad or mouse? I’m just wondering if the “lag” is endemic to the whole system, or specific to the touch screen.
Yes, it is consistent across different apps. Photoshop behaves like Paint, dragging a window behaves like doing anything else.
Weird quirk: by default, the BIOS is set to MPP. I switched it to USI, nothing changed. Switched it back to MPP, the stylus stopped working. Switched it back again to USI, it works again. I’m lost.
I don’t really have the time right now to test it on Linux. Might give it a shot during the weekend, but right now I really can’t.
I don’t have any other stylus I can test, I’m afraid. I don’t think it matters, though: my finger performs every bit as bad - same twitching/jerkiness. Ugh.
Using either the trackpad or a wired/bluetooth mouse is totally fine. Perfectly smooth.
I appreciate your help so much. English is not my first language, and I’m struggling to explain myself. Plus I’m a bit cranky about this ordeal. Does this video show the issue a little bit better? https://www.youtube.com/shorts/7m7KCwKHpBI
Huge shoutout to Framework Support. They helped me narrow this down in just a few days (it would have been even faster if I had replied more promptly on my side).
Since Safe Mode completely eliminated the touchscreen lag, I started isolating third-party services through a “clean boot process”, so to speak.
Long story short: the culprit was Framework Control
I had installed it shortly after setting up my FW12 to tweak fan behavior.
For reasons I can’t fully explain, it 100% interferes with the touchscreen sampling. With the service enabled, I would get intermittent stroke drops and straight-line artifacts while writing with both stylus and finger. In Safe Mode (or with the service disabled) the touchscreen works flawlessly.
My guess is that something in its power management or hardware polling routine conflicts with the ILITEK touch controller / I2C stack, but I don’t know for sure.
Yes, the FW12 fan can be a bit “enthusiastic” at times, but not nearly enough to justify broken touch input.
I hadn’t used Windows in over a decade and switched back specifically to buy this Framework laptop - which ROCKS, by the way. Seeing the stylus finally behave properly after chasing this issue for days was incredibly satisfying. I was so pissed, it was unusable before.
Hopefully this helps someone else avoid the same rabbit hole.
I’m sorry that my app caused you that much trouble
Now I’m curious why touch input is breaking… Did you have power controls enabled in the app? Was it breaking when you didn’t have a fan curve configured and just used the “auto” mode?
If power controls were disabled, the only tool the app should be interacting with is the “framework_tool” which is a CLI built by the Framework team that communicates with the embedded controller of the machine.
I’m glad you were able to solve the issue. I would have tested the same behavior myself and root cause of the issue, but I don’t own a Framework 12.
Oh, hi there! I didn’t expect to stumble upon you
You have NO idea, I was so pissed I was seriously thinking about returning my laptop
Because, you know, I installed your app immediately, therefore I’ve never seen my laptop’s touchscreen behave properly in over a month of owning it. I just thought it was THAT unsuitable for Windows 11. A bit of a prejudice on my part, I have to admit. But believe me, it was unbearable, and I spent the last couple of weeks troubleshooting.
It’s such a nice utility, though! I had set it up to manage maximum battery charge to 90%, calibrated the fan speed reading, and set it to a nice, gentle curve. That’s it. Reverting those settings to default did not help, I had to disable the app’s service in msconfig altogether to fix the issue.
I’ve uninstalled it for the time being, begrudgingly so. Hopefully a solution will eventually come up! I’m just so relieved, it’s such a great computer
Wow, that sounds very frustrating and is quite unfortunate but I’m glad you’ve resolved it and it’s working afterwards.
This really seems like a firmware bug that indicates a weird interaction between the “framework_tool” cli and the touchscreen.
If you’re feeling exploratory and ever want to help out, we may debug this and try to reproduce the issue with just some basic cli calls without my app running. If my theory is correct and this is actually a firmware bug, we can submit the bug to the “framework-system” repo and get a Framework devs attention.
Perfect! I put together a script that runs through the CLI operations one by one, each time running it for 20 seconds to allow you to try your stylus. You need the “framework_tool” CLI downloaded, which you can download from here.
The framework control app auto downloads it, but since you have it uninstalled, let’s download the latest from the original Framework repo.
Attaching the script here (this forum doesn’t allow ps1 files for security reasons), you need to run it in the same folder as the “framework_tool.exe” because it will try to call it. You will also need to run it from an administrator PowerShell window since the tool needs admin permissions to work.
Please let me know if you don’t feel comfortable or don’t know how to run the script. I can provide better instructions, or just shut up and allow you to enjoy your machine
Thanks for offering to help debug!
Also… It’s a good practice to read the script yourself or ask your AI tools to review it before running it. You should be cautious about running scripts that come from random strangers online, especially if they ask you to run is as administrator
The embedded controller (EC) is a slow single threaded processor.
There are elements of the CPU that make requests to the EC and if those requests are not responed to quickly enough, it will slow the entire CPU down. This can also cause events managed by the EC to be dropped or missed.
So, running a tool that makes more than the occasional request to the EC will likely cause problems.
I don’t know how many request the “framework_control” app makes to the EC, but it might be causing the problem described here.
The below issue is for the FW16, but all ECs are similar.
