0

Before anyone asks, Yes I've made sure the keyboard itself is not the problem, the two keys in question work fine when I hold shift to make curly brackets, and the they do properly type square brackets in for other computers. I was coding along in visual studio code, and found that my square bracket keys stopped working, they work fine when I hold shift to create curly brackets though. I restarted my computer several times but no luck, after I did some digging and used the xev command.

FocusOut event, serial 36, synthetic NO, window 0x4200001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 36, synthetic NO, window 0x4200001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 36, synthetic NO, window 0x0,
    keys:  68  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

FocusOut event, serial 36, synthetic NO, window 0x4200001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 36, synthetic NO, window 0x4200001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 36, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0 

That is what happens when I hit the square bracket keys, I think some other program is interrupting the square bracket from going through, atleast, that is what I've gotten from all my digging. Problem is, I have no clue what program that would be. It happens even when I just freshly booted the machine. When I go to Settings->Keyboard and try to bind the keys to something, it recognizes them and will even allow me to bind them for existing commands. Any ideas what could be causing this?

--Update--

Mar 26 19:33:49 MinervaUBU /usr/lib/gdm3/gdm-x-session[1262]:     detail 1 (mask 0), modifiersDetail 79 (mask 0)
Mar 26 19:33:49 MinervaUBU /usr/lib/gdm3/gdm-x-session[1262]:     device 'Virtual core pointer' (2), modifierDevice 'Virtual core keyboard' (3)
Mar 26 19:33:49 MinervaUBU /usr/lib/gdm3/gdm-x-session[1262]:       xi2 event mask 0x70 0 0 0
Mar 26 19:33:49 MinervaUBU /usr/lib/gdm3/gdm-x-session[1262]:     owner-events false, kb 1 ptr 1, confine 0x0, cursor 0x0
Mar 26 19:33:49 MinervaUBU sudo[21324]: pam_unix(sudo:session): session closed for user root
Mar 26 19:33:49 MinervaUBU sudo[21326]: epicrangerpig : TTY=pts/0 ; PWD=/home/epicrangerpig ; USER=root ; COMMAND=/usr/bin/xdotool keyup XF86AudioMute
Mar 26 19:33:49 MinervaUBU sudo[21326]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 26 19:33:49 MinervaUBU sudo[21326]: pam_unix(sudo:session): session closed for user root
Mar 26 19:33:56 MinervaUBU sudo[21328]: epicrangerpig : TTY=pts/0 ; PWD=/home/epicrangerpig ; USER=root ; COMMAND=/bin/journalctl -f
Mar 26 19:33:56 MinervaUBU sudo[21328]: pam_unix(sudo:session): session opened for user root by (uid=0)

--Edit 2--

Solved the problem myself. I was in fact my own fault, I had made a Xbindkeys profile at one point when I was very tired and forgot about it! Stopped Xbindkeys and removed the profile and all is good!

1 Answer 1

0

You can use xdotool to log the 'Grab' information:

KEY=XF86AudioPlay
xdotool keydown ${KEY}; xdotool key XF86LogGrabInfo; xdotool keyup ${KEY}

X11 'Grabs' will be logged. Newer systems can see these details in the journal $ sudo journalctl -f, while older systems may find the logs in /var/log/Xorg.0.log. This shows you which X11 application is capturing or intercepting the key.

If this doesn't work, can you provide details of the behavior before X loads?

1
  • I tried the command you posted but nothing is happening, all it seems to do is simulate if the KEY Button is pressed. I updated the question with the output of the journal.
    – Epicranger
    Mar 27, 2019 at 0:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .