Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
tyetye opened this issue Feb 22, 2019 · 13 comments
Closed

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

tyetye opened this issue Feb 22, 2019 · 13 comments
Labels
bug core help wanted stale Issues or pull requests that have become inactive without resolution.

Comments

@tyetye
Copy link

tyetye commented Feb 22, 2019

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
Copy link

@pelrun
Copy link
Contributor

pelrun commented Feb 23, 2019

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
Copy link
Contributor

pelrun commented Feb 23, 2019

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

@tyetye
Copy link
Author

tyetye commented Feb 27, 2019

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
Copy link
Contributor

pelrun commented Feb 27, 2019

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

@tyetye
Copy link
Author

tyetye commented Mar 3, 2019

(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
Copy link
Author

tyetye commented Mar 22, 2019

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
Copy link
Author

tyetye commented Apr 8, 2019

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
Copy link

eyemyth commented May 25, 2019

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
Copy link
Author

tyetye commented May 27, 2019

@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
Copy link

stale bot commented Nov 21, 2019

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
Copy link

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.

@github-actions github-actions bot added the stale Issues or pull requests that have become inactive without resolution. label Jun 17, 2022
@tzarc
Copy link
Member

tzarc commented Jun 18, 2022

Closing due to inactivity.

@tzarc tzarc closed this as completed Jun 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug core help wanted stale Issues or pull requests that have become inactive without resolution.
Projects
None yet
Development

No branches or pull requests

6 participants