X events getting clogged up?
#1
I'm using my PBP with the original mrfixit Stretch, and X.  I noticed that sometimes the mouse (touchpad) pointer gets stuck.  Often I can't find  the mouse pointer just because there are places it's an I-Beam which isn't very visible.  If it gets stuck in one of those places it takes a while to find it.

I've done a little xlib programing so I know that there's a stream of events constantly (almost) being processed.  See man pages like XtNextEvent, XtPending, XtMainLoop.  I suspect something's causing these to not get cleared fast enough at times.  If my cursor won't move I just let it sit a minute and then it works again.  Sometimes more down pressure helps a little but not much.
  Reply
#2
In case you don't know, the touchpad controller is wired via a serial port, (I2C I think), to the keyboard controller. Then the keyboard controller is wired to an internal USB 2.0 hub. Which is then wired to a RK3399 USB 2.0 port. Since these are low speed devices, it should work fine.

From what I understand, (and my knowledge is limited), the touchpad firmware has a minor bug which causes it to send out empty or useless packets. Nothing that would cause Linux to crash. Newer kernel drivers will toss out those packets, reducing the overhead. But, since you are on the original Mr.Fixit Debian, it might not have the "fix". So the packets leave the kernel and X-Windows drivers have to then toss them out.

Anyway, that's about what I know. Their IS a problem with the touchpad. A fix in the kernel driver can work around it. And in general, most people aren't affected by it.


Ideally, the keyboard replacement firmware project would either fix those touchpad packets or toss them. At least until we can get the touchpad firmware fixed.

I can get you a link to the replacement keyboard firmware project, if you want. (Their are forum postings about it too...)
--
Arwen Evenstar
Princess of Rivendale
  Reply
#3
Nah, thanks, that's OK.  I'm on the Debian ARM mailing list and watching for mainstream Debian to support the PBP.  There are daily builds that might but I've misplaced my console serial adapter and last I knew you needed one of those to get it installed.  Someplace like https://d-i.debian.org/daily-images/arm64/.  They seem to concentrate on images for doing netboot which I don't think the PBP can do.  There's an installer using grub at https://d-i.debian.org/daily-images/arm6...ler/arm64/  And they're trying to cover all ARM64 by having concatenateable images.

There's a way to build a PBP image from what's at https://d-i.debian.org/daily-images/arm6...rd-images/ I just haven't fiddled much with it.

So this is the dreaded firmware problem.  OK, it's not so awful.
  Reply
#4
I did the firmware update finally. I wasn't sure if it would be beneficial, my PBP arrived on January 13, 2020 so I was trying to guess if it belonged to one of the batches with a bug or not.

After step 1 I connected by ssh from a phone (Termux) to finish. I haven't used it enough to see if this cured the clogged up problem.
  Reply
#5
The problem mostly seems to be cured.  There are times still when I can't move the cursor.  Wetting my fingertip by licking it sometimes changes the capacitance enough to make it move, or maybe using more down pressure.  How sensitive it is to either seems to keep changing.  But almost always letting it sit a minute or two helps.

Finding a lost cursor when the touchpad isn't working so you can't see it move is a bear.

What I didn't expect is the reliability improvement.  I actually have a question on a Debian forum about how i can find the cause of sporadic reboots.  It's been up 1 day 20 hours now, it didn't do that before.

-----------

Other misc. usage tricks I'm picking up: You can feel the lower corners of the trackpad indentation even in the dark, that's where you should be clicking for the buttons. You can also click (and hold) the left button with your left hand while dragging a vertical scroll bar with your right hand.
  Reply
#6
This has been on the tip of my mind for a week or more and I finally realised what I wanted to say.

Get xeyes! This is one of the classic X applications and is exactly what you need. You might even have it already.
  Reply
#7
Yup, I have xeyes, just tried it.  Except it's just for amusement, right?  I used to have other things like Neko and xsnow.

Just an aside on such things, back in the mid 1980s the college I was working at got I think a Silicon Graphics workstation. I didn't have much to to with it really but there was this spider program that would walk across the screen toward where ever you moved the mouse. The leg joints moved and everything. I'd like to find a copy of that now, I've looked some. OpenGL maybe.

I'm wondering if there's a connector inside that isn't making a good connection.  I looked at a replacement touchpad at $7 but $18 shipped.  I should try it booted from another OS first.  It acted up easily a dozen times today.  But just letting it sit about a minute cleared it up every time.  Replacing the firmware didn't actually accomplish anything, it just seemed it at first.  Still rebooting too.
  Reply
#8
Well xeyes always looks in the direction of the mouse pointer, so if you ever wonder where it is, there it is. I've been running it at startup, and the only issue is that it gets covered up at times.

As for the spider, I had one for the Amiga once like that, but it was a worm or a snail or something. There was something nefarious about it too, don't recall what it was. Maybe it ate or stole the pointer if it caught up to it, or something. I had a virus one time the reversed the direction of movement. Turning the mouse upside down thwarted that too well, but I decided to use it as-is for a while. Like a Dvorak keyboard, or inverting lens glasses, it would've been just fine if I didn't have to use a computer at work.
  Reply
#9
For finding the mouse, I think Windows can do this too, if you hold down the ctrl key by itself the cursor gets big or changes color or something. With X different processes own the cursor, I'm not sure it would be possible. You mean run it like xeyes &, didn't think of that.

The cursor can go off the right and bottom sides, but the left and top are the origin, it won't go past those. So try to move it to the upper left corner. I have been able to get some stuff done because I use the Joe editor and mc, neither needs a mouse. I haven't lost any work due to the reboots because i save often. I did discover it's not such a tidy reboot. If I run fsck -fy on my nvme partition I'm working in there's almost always something for it to do. I was thinking it was a reboot that was unmounting first. upower is still removed. I don't supose there's a diagnostic program?
  Reply
#10
OK, I've got xeyes running on all desktops. Even if I can't find the cursor it'll give me a clue as to whether the mouse coordinates stop coming through. If xeyes stops moving when I move the mouse that's what I'm looking for. Gimp provides non-stop coordinates but only within Gimp. Maybe it's worth taking a look at xeyes source. It has access to mouse coordinates while the mouse is in other programs, I need to look at how they did that. I've made a couple LXDE plugins, it wouldn't be that hard to have mouse coordinates displayed in the system tray.

https://gitlab.freedesktop.org/xorg/app/xeyes XtInsertEventTypeHandler is the key, got the man page for it up.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  acpi "ac_adapter" events elijahr 2 3,859 09-24-2020, 09:28 PM
Last Post: elijahr

Forum Jump:


Users browsing this thread: 2 Guest(s)