On 21/07/14(Mon) 17:32, Mike Burns wrote: > A partial reply; I have not yet run your patch: > > On 2014-07-21 16.00.01 +0200, Martin Pieuchot wrote: > > More seriously, can you plug external USB devices to your laptop and see > > if they are correctly recognized? Do they attach to uhub2 or uhub3? > > That seems to always work, regardless of whether the mouse works, and > regardless of whether wsmoused is running. It looks like this: > > umass0 at uhub2 port 2 configuration 1 interface 0 "SanDisk Cruzer" rev > 2.00/2.00 addr 6 > umass0: using SCSI over Bulk-Only > scsibus4 at umass0: 2 targets, initiator 0 > sd2 at scsibus4 targ 1 lun 0: <SanDisk, Cruzer, 8.02> SCSI0 0/direct > removable serial.0781553001117562C886 > sd2: 30547MB, 512 bytes/sector, 62562239 sectors
In your previous dmesg your touchscreen attaches itself to uhub3, when you plug a device like this one, does it always attaches to uhub2? In other words, does something, somehow, sometimes attach to uhub3? > > > After resume, my normal mouse no longer works. > > > > Even if you restart X? Does it work after suspend/resume under > > wsmoused(8)? > > This is more erratic than I had anticipated, too. > > The mouse seems to always work under X if I suspend/resume _without_ > wsmoused. In fact, suspend/resume seems to always work if I do not have > wsmoused running. > > With wsmoused running, sometimes it works flawlessly (or so it seems). I > did get it to resume without a working mouse twice. I had a terminal > open with focus, so this fixed it: > > xinput -disable /dev/wsmouse > xinput -enable /dev/wsmouse Yeah, there's another problem while resuming X with a wsmoused(8) and the pms(4) driver... So if your mouse works after resuming with wsmoused(8) only or X only, that's not a new bug. > > Could you also check if you have a "disable legacy" option in your BIOS > > that would make your keyboard and mouse appear as USB devices once > > toggled. Could you try that if it exists? > > No such thing. The most relevant USB option is: > > USB 3.0 mode: Auto > > With the explanation for Auto (the current value): > > Connects and routes appropriate USB 3.0 or 2.0 ports. > > But that option is irrelevant to this (I think). Maybe, maybe not. You can try to disable it until we enable xhci(4) and see if that changes anything. > > If the systems immediately "resumes" by itself that means something > > failed in the suspend path. Could you try the diff below and tell me > > if you get more information? > > I'll get back to you on this, hopefully in 24 hours. > > > > Here's a dmesg from a successful suspend/resume: > > How many suspend resumes did you do? > > You caught me: I had done a few and tried to mark them, but lost track. > You got it right. > > Additional note: without X ever running, suspend/resume works fine, > regardless of whether wsmoused is running. If wsmoused is running and X > has never been started, the mouse continues to work after resume. > > However, if I log into a console, zzz, resume, then startx, it fails. I > get back to the console with ctrl-alt-backspace. Trailing output from > startx: > > Loading extension GLX > Agent pid 24099 > Identity added: /home/mike/.ssh/id_rsa (rsa w/o comment) > xterm: fatal IO error 35 (Resource temporarily unavailable) or KillClient on X > server ":0" > XIO: fatal IO error 35 (Resource temporarily unavailable) on X server ":0" > after 107 requests (98 known processed) with 0 events remaining. > XIO: fatal IO error 35 (Resource temporarily unavailable) on X server ":0" > after 138 requests (128 known processed) with 0 events remaining. > (EE) Server terminated successfully (0). Closing log file. > xterm: Xt error: Can't open display: :0 > xinit: connection to X server lost > > waiting for X server to shut down .......... > xinit: X server slow to shut down, sending KILL signal That's a known issue. If you suspend before starting X with a card supported by drm(4) you won't be able to start X after resuming.
