A Smaller Xwhatsit

User avatar
DMA

17 Feb 2020, 08:22

Layout loading is slow for a Reason. Creating nKeys*nLayers combo boxes is huge amount of work.

I also have this problem. It takes so much time to create those controls my firmware thinks FC is gone and goes out of setup mode. I probably need to increase that delay to like 10 seconds.

Ellipse

04 Mar 2020, 16:32

Could anyone help with a fix for the xwhatsit firmware issue described by webwit?
webwit wrote:
03 Mar 2020, 22:37
Here's one experiment and possible firmware bug why a simultaneous release fails on the F62, where it could be a matter of a few microseconds or single scan cycle registering the release of a one key over anther to cause this problem, where it does not on a HHKB:

On the HHKB: If I press Fn and then ` and keep them pressed, it keeps Del pressed. When I then release Fn but keep ` pressed, it keeps registering Del's.

On the F62: If I press Fn and then ` and keep them pressed, it keeps Del pressed. When I then release Fn but keep ` pressed, it starts registering ` being pressed.

It shouldn't do that, and problem is fixed.

Or something like that. Smells even stronger to the software now.

EDIT: Shift and Ctrl behave the same way on both the HHKB and the F62, that is, like the Fn on the F62, when you release the controlling key but not the other key, it starts to register the other pressed key, but after a brief pause. That pause might fix it too.
webwit wrote:
03 Mar 2020, 21:02
Here's a video. It happens when making quick combinations with the Fn key which are no problem on other keyboards, hardware or software Fn. Doesn't matter where I program the Fn key, so it's not a faulty key. Programmed the Fn on both layers. If you play it at the slowest speed when I'm typing and pause frequently, you see the Fn key registering and then the ` and they will register together very briefly but still gives BOTH a Del and ` instead of just Del. Firmware? It's also Fn plus cursor keys etc. I have no problem with shift and ctrl. That reeks to the software implementation of Fn? It can't like cope with the simultaneous release of the keys.

User avatar
DMA

04 Mar 2020, 18:56

Ellipse wrote:
04 Mar 2020, 16:32
On the HHKB: If I press Fn and then ` and keep them pressed, it keeps Del pressed. When I then release Fn but keep ` pressed, it keeps registering Del's.
This is incorrect behavior. _conceptually_ incorrect behavior.

The correct behavior on Fn up would be to release the Del, and out of courtesy not press anything. Fn is a momentary action switch, the moment it's up it's effect should cease.

The "out of courtesy" is an important word. Because firmware is totally free to release the Del and press the backtick when Fn is released. Because, again, Fn is a momentary action key. The moment it's released it's effect must cease.

Update: This nicely highlights all these "modifier keys internal to keyboard" problems. Keyboard only exists as a software state at the host. Connect 3 keyboards, press Ctrl on first, Alt on second, Del on the third - and you'll still get Ctrl-Alt-Del. But local-to-keyboard Fn is a different beast.

Update 2: it is kind of ironic that you ask for free tech support for a commercial product here. Yours is not a community project, hire yourself a programmer.

User avatar
zrrion

04 Mar 2020, 20:34

>anyone asks for help
>DMA is a bitch needlessly
You hate to see it

When fn is released del shouldn't be as you only send up codes when the key is actually released. Sending an up code while the key is still down isn't consistent and certainly not how it is done with soarers, I don't remember how it is handled with QMK/TMK but I suspect it waits for key release to send an up code.

User avatar
wcass

04 Mar 2020, 21:38

If [Del] is defined as [Fn+`] then [`] (without Fn) should unequivocally be [`]

On the HHKB, if you do [Shift+`] and hold the [`] but let go of the [Shift] what do you get? Which of the below seems more correct?
~~~~~~~~~~~~~~~~~```````````````````````
or
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Have you been able to replicate Webwit's problem?

User avatar
DMA

04 Mar 2020, 22:55

zrrion wrote:
04 Mar 2020, 20:34
>anyone asks for help
>DMA is a bitch needlessly
You hate to see it
Glad to be of service!
zrrion wrote:
04 Mar 2020, 20:34
When fn is released del shouldn't be as you only send up codes when the key is actually released. Sending an up code while the key is still down isn't consistent and certainly not how it is done with soarers, I don't remember how it is handled with QMK/TMK but I suspect it waits for key release to send an up code.
Au contraire, my friend. You send all the keys that are currently pressed. You send update on change only if host told you so (to conserve USB bandwidth), but host can just throw a Set_Idle with a non-zero period at you at any moment - it doesn't even need a reason. And then you'll have to report periodically.
Most people cannot be bothered to implement USB HID correctly, of course. :)

User avatar
webwit
Wild Duck

05 Mar 2020, 17:14

wcass wrote:
04 Mar 2020, 21:38
Have you been able to replicate Webwit's problem?
I have managed to replicate it myself - Besides the F62 I also have a F77. Same thing: Fn + Layer 1 key sometimes gives an additional Base Layer char upon release of both keys.

I don't know what the proper method is, HHKB or other, but that's besides the point that I do know that this firmware has got it wrong. If you release two pressed keys simultaneously, then, by the order of things which is how computers work, it will register one key being released over the other. The firmware seems to take the situation too literary, immediately sees the other is not yet released and outputs that character. It should at least wait the very small amount of time when two buckling springs are released between the winner and loser of the who-is-first contest.

User avatar
webwit
Wild Duck

05 Mar 2020, 17:16

Good god, the weight of that F77. :shock:

User avatar
webwit
Wild Duck

09 Mar 2020, 19:29

I'm putting a bounty of one IBM 4704 50-key* (not refurbished) on the best working fix for above problem in the xwhatsit IBM Capsense released under GPLv3:

Image

* If you fancy something else that's negotiable too of course.

orihalcon

10 Mar 2020, 00:52

Just curious, does this same thing happen with other Xwhatsit controllers, or is it just the batch that was used in Ellipse's reproductions? I believe he used a more "compact" version, just wondering if the full size version has that issue as well as this is the first I've heard about it.

Webwit, do you have any other Xwhatsit converted boards (with original hardware design) to test to see if they have the same issue too?

User avatar
webwit
Wild Duck

10 Mar 2020, 11:01

I don't have any others.

User avatar
webwit
Wild Duck

14 Mar 2020, 14:00

I found a temporary fix:

Use capsense to remap right control to another left control, then use autohotkey to map the freed right control as a hhkb Fn key.

Still hoping for a better fix.

User avatar
DMA

22 Mar 2020, 20:41

wcass wrote:
18 Apr 2016, 22:30
If you build a better controller, the (keyboard) world will beat a path to your door.
Hello from the past :)
I'm not sure it really panned out that way - but mostly.

pandrew

Yesterday, 12:13

I'm working on porting QMK to xwhatsit boards. Is there anyone around here who would like to help me by testing my code on a Beamspring rev.3 or rev.4 xwhatsit board ?

pandrew

Yesterday, 12:15

PS, in case you're not following Ellipse's model F thread, webwit's problem has been solved by me here: viewtopic.php?p=461764#p461764

Post Reply

Return to “Workshop”