Closed tckmn closed 6 years ago
I'm not seeing the rules.mk (it's just a link to keymap.c, and trimming the /keymap.c shows a list of things not including a rules.mk).
My rules.mk for my keyboard using this just has STENO_ENABLE = yes
, and that seems to work.
[1228506.880367] input: ErgoDox EZ ErgoDox EZ as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7.1/1-7.1:1.0/0003:FEED:1307.036D/input/input590
[1228506.936069] hid-generic 0003:FEED:1307.036D: input,hidraw0: USB HID v1.11 Keyboard [ErgoDox EZ ErgoDox EZ] on usb-0000:00:14.0-7.1/input0
[1228506.937941] input: ErgoDox EZ ErgoDox EZ as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7.1/1-7.1:1.1/0003:FEED:1307.036E/input/input591
[1228506.991697] hid-generic 0003:FEED:1307.036E: input,hidraw1: USB HID v1.11 Device [ErgoDox EZ ErgoDox EZ] on usb-0000:00:14.0-7.1/input1
[1228506.993273] hid-generic 0003:FEED:1307.036F: hiddev0,hidraw2: USB HID v1.11 Device [ErgoDox EZ ErgoDox EZ] on usb-0000:00:14.0-7.1/input2
[1228506.993491] cdc_acm 1-7.1:1.3: ttyACM0: USB ACM device
@seebs The rules.mk
is on the same page as the keymap (scroll down to the bottom). It contains STENO_ENABLE = yes
, but that doesn't seem to be working.
Hmm. Okay, experiment time: Try turning off NKRO_ENABLE, and possibly CONSOLE_ENABLE. There's code to check for running out of endpoints, but then I noticed:
OPT_DEFS += -DINTERRUPT_CONTROL_ENDPOINT
And I don't know the endpoint stuff well, but it occurred to me that I could easily imagine the system being smart enough to detect features with too many endpoints, but not smart enough to detect that this -D is also adding an endpoint...
I checked more, that probably isn't it, because there's other keyboards with the same thing that aren't doing this. So I'm not sure. I'm still a little suspicious about the endpoint thing.
Do other USB serial things work on this system? Is it possible that you have a kernel that omits the relevant support? I know arch users (like me...) have been known to optimize a kernel by dropping hardware they didn't need...
@seebs Ah, good call, it was indeed a kernel thing. I had forgotten to reboot after upgrading my kernel, so the required modules probably weren't getting loaded. Sorry about that, and thanks!
For me, I need to run plover with sudo. I guess the virtual serial is not accessible from normal user.
Serial port accessibility is a configuration choice you'd make elsewhere; usually there's a group that gets access to the port, and you'd need to add your user account to it. You should not need root to access a serial port in normal use.
I have followed the instructions on the Stenography page of the QMK documentation by configuring both my QMK layout and Plover for steno over virtual serial port. However, I can't get any output with either TX Bolt or Gemini. Nothing happens when I press one of the steno keys or try to stroke a chord.
After some investigation, it seems that no virtual serial port is being created, based on the output of
dmesg
.Here are my
keymap.c
andrules.mk
; I've also tried thesteno
layout from the QMK repository with the same (non-)results.The
dmesg
output when I unplug and reconnect my Planck is as follows:dmesg | grep tty
yields only the following:And here's the output of
xinput --list
, in case that helps:This is what my Plover config looks like (if I try "Scan," the only result is
/dev/ttyS0
):I'm using a Planck on Arch Linux with Plover 4.0.0.dev3 and the latest version of the QMK repository.
Thanks!