Page 4 of 4
Re: A Smaller Xwhatsit
Posted: 17 Feb 2020, 08:22
by DMA
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.
Re: A Smaller Xwhatsit
Posted: 04 Mar 2020, 16:32
by Ellipse
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.
Re: A Smaller Xwhatsit
Posted: 04 Mar 2020, 18:56
by DMA
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.
Re: A Smaller Xwhatsit
Posted: 04 Mar 2020, 20:34
by zrrion
>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.
Re: A Smaller Xwhatsit
Posted: 04 Mar 2020, 21:38
by wcass
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?
Re: A Smaller Xwhatsit
Posted: 04 Mar 2020, 22:55
by DMA
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.
Re: A Smaller Xwhatsit
Posted: 05 Mar 2020, 17:14
by webwit
wcass wrote: 04 Mar 2020, 21:38Have 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.
Re: A Smaller Xwhatsit
Posted: 05 Mar 2020, 17:16
by webwit
Good god, the weight of that F77.
Re: A Smaller Xwhatsit
Posted: 09 Mar 2020, 19:29
by webwit
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:
* If you fancy something else that's negotiable too of course.
Re: A Smaller Xwhatsit
Posted: 10 Mar 2020, 00:52
by orihalcon
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?
Re: A Smaller Xwhatsit
Posted: 10 Mar 2020, 11:01
by webwit
I don't have any others.
Re: A Smaller Xwhatsit
Posted: 14 Mar 2020, 14:00
by webwit
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.
Re:
Posted: 22 Mar 2020, 20:41
by DMA
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.
Re: A Smaller Xwhatsit
Posted: 31 Mar 2020, 12:13
by pandrew
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 ?
Re: A Smaller Xwhatsit
Posted: 31 Mar 2020, 12:15
by pandrew
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
Re: A Smaller Xwhatsit
Posted: 05 Apr 2020, 00:37
by DMA
Welcome to the club.
Layers problem has a much simpler solution: just detect "last physical key released" event and clear USB reports on that. No need to store any layer-dependent state - frees up both memory and CPU cycles.
PS: moving tripping point to zero is pretty cool. Fully symmetric algo. Will probably steal next time I'm passing thru scan module. 126 debouncing steps in a single byte - nice.
Re: A Smaller Xwhatsit
Posted: 23 Sep 2021, 03:18
by wcass
I have been asked about licensing and for DipTrace files.
I consider the work i did for this trivial. Any differences between my design and Tom Wong-Cornall's original should be considered licensed the same as the original (GPLv3 iirc).
Attached is the micro USB DipTrace file. Again i am having trouble finding where i put the USB-C version. If someone asks for it, i will keep looking or remake it.
Re: A Smaller Xwhatsit
Posted: 23 Sep 2021, 05:13
by Ellipse
Thanks wcass. Here are my copies of the USB-C project files, one being the 2021 version with a 10k resistor pack removed and the other being the 2019 update with USB-C added and the ATMEGA chip package changed.
Re: A Smaller Xwhatsit
Posted: 23 Sep 2021, 05:17
by wcass
i just came back to upload after finding it and you did it less than a minute ahead of me.