qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.09k stars 38.89k forks source link

Can't compile for Proton C when using PS2_MOUSE_ENABLE #5218

Closed tyetye closed 2 years ago

tyetye commented 5 years ago

I am working on a new custom keyboard using the Proton C and would like to add a Trackpoint to it. QMK currently still compiles for Teensy and related controllers when using the PS2_MOUSE_ENABLE flag. However, compile fails when building with the QMK skeleton Proton C keyboard.

Is this a feature that can be easily ported to the Proton C? If so, is it something that will likely be ported soon?

The command I used to compile is: make proton_c:default PS2_MOUSE_ENABLE=yes PS2_USE_INT=yes

The compile error is:

Compiling: tmk_core/protocol/ps2_mouse.c
tmk_core/protocol/ps2_mouse.c:19:19: fatal error: avr/io.h: No such file or directory
#include<avr/io.h>
compilation terminated.
classabbyamp commented 5 years ago

https://www.reddit.com/r/olkb/comments/asq7lc/ps2_mouse_on_proton_c/

pelrun commented 5 years ago

The ps2 mouse code is definitely avr-only at the moment. That said, it doesn't look too hard to convert over to the platform-agnostic API, if you just use the busywait implementation and not the interrupt one.

pelrun commented 5 years ago

Dodgy attempt here: https://github.com/pelrun/qmk_firmware/tree/ps2-port

tyetye commented 5 years ago

Thank you, @pelrun.

I was just able to get back to this today. The BUSYWAIT implementation now compiles. I'll try to breadboard it with a physical Trackpoint soon.

Do you know if the other implementations, INTERRUPT/USART, are also possible? The documentation strongly implies that the BUSYWAIT implementation is not very good (unwanted input and "jerky movement"). I think @galengold believes that the INTERRUPT implementation will work with the Proton C but not USART.

pelrun commented 5 years ago

It can be made to work, but the current interrupt implementation is absolutely AVR only.

tyetye commented 5 years ago

(maybe a new issue should be opened, or title changed, since the code now compiles, but I'm having new problems)

Well, I don't know what's going on. I cannot get any Trackpoints working, not even one which previously worked with my existing Teensy based Ergodox. I am now referring to the main QMK, not @pelrun 's ps2-port branch.

Can someone else verify that the current QMK release can drive a Trackpoint using a Teensy/ATmega32u4? I would like to rule out user error on my part or something changing in QMK, since it has been over a year since I updated QMK on my Ergodox.

I have two bare Trackpoints which I have been trying to get working with QMK for the last week using my breadboard. I have tried to get them working with both Proton C and Teensy 2.0, using PS2_USE_BUSYWAIT=yes. The only response I ever got out of it was a random right click after the controller booted up -- then silence. I can still short pins to get keyboard output, but no mouse pointer movement, and no mouse key presses. So, I know the firmware is working in some capacity.

Additionally, I have an Ergodox build that I did a couple of years ago with an integrated Trackpoint. I stopped using that keyboard well over a year ago but the Trackpoint and all mouse buttons worked perfectly on it. So, I know the hardware was solid at that time. I tried flashing the current version of QMK on it and now the Trackpoint doesn't work on that Ergodox also.

tyetye commented 5 years ago

Can @pelrun or anyone familiar with the Proton C offer any more help? I have made a little progress.

As noted above, a couple of my Trackpoints are broken for some reason. However, I have one working perfectly with my Teensy board right now. I am now trying to get that one working with the Proton C.

Set up: I am using the Trackpoint with the Proton C. I have the required circuitry (pull up resistors and capacitor) between the Trackpoint and the Proton C. I have the RESET wire enabled. I am using @pelrun's ps2-port, here In config.h, I have #define PS2_CLOCK_PIN B5 & #define PS2_DATA_PIN B4 . In keymap.c, debug_enable=true & debug_mouse=true. I am compiling with sudo make proton_c:default:dfu-util PS2_USE_BUSYWAIT=yes PS2_MOUSE_ENABLE=yes CONSOLE_ENABLE=yes.

Using hid_listen, after the board boots up, hid_listen shows "keyboard start". After that, it mostly just repeats ps2_mouse: fail to get mouse packet. However, every few seconds, hid_listen outputs x10, x08, or x04. I cannot manually move the mouse cursor, but at random times, the mouse cursor will move down a few pixels or register a right click. QMK is definitely aware of the Trackpoint in some manner because, if I change the clock pin and data pin to something else, hid_listen does not output the right click and x10 type output.

The QMK docs here, show a lot of additional information to be used with BUSYWAIT. @pelrun doesn't mention needing this with his port. I am not sure if this is Proton C specific or if it is just not needed?

So, main question is am I doing anything obviously wrong? If not, what is the best way to proceed?

IMG_20190322_003715

tyetye commented 5 years ago

Made some progress! The Trackpoint now works with the Proton C -- but there are still some big issues. Using @pelrun's ps2-port branch here.

The set up is very particular about which controller pins are used with the Trackpoint. The best configuration I have found so far is:

#define PS2_CLOCK_PIN B0
#define PS2_DATA_PIN B14

Using that combination of pins, the Trackpoint cursor movement seems as smooth as when using a Pro Micro or Teensy 2.0.

However, there are still two issues:

  1. Occasionally, the Trackpoint will just stop responding. Sometimes, it will work for hours. Sometimes, just for minutes. But eventually, it stops moving the mouse cursor and I have to power cycle the Proton C.
  2. The "menu key" on the keyboard is sent sporadically. I can't figure out the pattern but it happens every few minutes. I originally noted this behavior in a previous comment as sending "random right click". Since then, I've realized it's not a right click, it's a menu key keypress.

Additional Information: If I use

#define PS2_CLOCK_PIN B0
#define PS2_DATA_PIN B1

then it works as described above, but the cursor movement stutters a lot. It moves the cursor, as expected, but is totally unusable as a pointer because of the jerky movement.

Using other pins means the movement stutters so much that the cursor is completely unpredictable or does not move the cursor at all. For example, I can't get any of the "A" pins to move the cursor.

eyemyth commented 5 years ago

Hi @tyetye, just curious if you made any changes between your last two comments. I'm trying to get a trackpoint working too, but using a Teensy 3.2 (which is also ARM-based). I can compile using @pelrun's fork, but I just get ps2_mouse: fail to get mouse packet endlessly in the console. Incidentally, it also makes my keyboard stop working. I'm using an actual Thinkpad keyboard wired up to the Teensy. My situation is probably also complicated by the inclusion of ChibiOS.

tyetye commented 5 years ago

@eyemeth. Unfortunately, no changes or progress since the last post. I think someone with more knowledge/skill than me just needs to spend time on this. In the meantime, I decided to build the new PCB around an Elite-C and leave extra room on the PCB at the tail end of the Elite-C. Hopefully, that will make swapping to a Proton-C fairly trivial when QMK catches up.

stale[bot] commented 4 years ago

This issue has been automatically marked as resolved because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

tzarc commented 2 years ago

Closing due to inactivity.