Author Topic: The SpaceFN layout: trying to end keyboard inflation  (Read 123302 times)

0 Members and 1 Guest are viewing this topic.

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1662
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #100 on: Mon, 23 December 2013, 16:57:19 »
it is actually a gh60 rev.a that I am flashing tmk firmware to. poker layout....
I am building a friendly layout editor in c# based on hasu's tmk firmware for the gh60.

A friendly editor for Hasu's firmware, a very nice idea!

I think it would be very easy for this editor to be usable for all variants of Hasu's firmware, including his HHKB mod, the PS/2->USB converter, the HID liberation and so on.

Are you writing it under Windows or Linux? I can test it for you under Linux and Mac OS if you want. I think Winforms is supported under Linux, but I'm not sure about Mac OS. The few projects I have written in C# I wrote them under Linux with GTK# as the GUI frontend and then tested them on Windows and Mac OS. It was 3 years ago. I know C# + GTK# is really portable, I'm not sure about C# + Winforms.

I have a GH60 rev.A, several PS/2->USB adapters and Hasu's HHKB mod. So I can test for all these variants.


asp.net webservice...

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #101 on: Mon, 23 December 2013, 18:25:48 »
it is actually a gh60 rev.a that I am flashing tmk firmware to. poker layout....
I am building a friendly layout editor in c# based on hasu's tmk firmware for the gh60.

A friendly editor for Hasu's firmware, a very nice idea!

I think it would be very easy for this editor to be usable for all variants of Hasu's firmware, including his HHKB mod, the PS/2->USB converter, the HID liberation and so on.

Are you writing it under Windows or Linux? I can test it for you under Linux and Mac OS if you want. I think Winforms is supported under Linux, but I'm not sure about Mac OS. The few projects I have written in C# I wrote them under Linux with GTK# as the GUI frontend and then tested them on Windows and Mac OS. It was 3 years ago. I know C# + GTK# is really portable, I'm not sure about C# + Winforms.

I have a GH60 rev.A, several PS/2->USB adapters and Hasu's HHKB mod. So I can test for all these variants.


asp.net webservice...

OK, you mean we will be able to design the layout in a web browser and download the hex file or the keymap_*.c file at the end of the process?

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1662
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #102 on: Mon, 23 December 2013, 20:44:12 »
yes. I want to start with the gh60 because that is all I have to test on. later I can expand to phantom and other stuff.

Offline yasuo

  • Posts: 976
  • Location: ID
  • spanengan puyeng newbie
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #103 on: Tue, 21 January 2014, 09:18:52 »
I download full now,but stand-alone exe v0.2.1 can't :( i uses win7 but not compatible in written :confused:
so try Zip  files :)
« Last Edit: Tue, 21 January 2014, 09:37:34 by yasuo »
Logitech MK220 Colemak DH
SplitSyml by Moz BlacksMx fuk blacks

2/3 8.5pm                                          in de la my september month ya da all get my fukka "fake message"

Offline daerid

  • Posts: 4271
  • Location: Denver, CO
    • Rossipedia
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #104 on: Tue, 21 January 2014, 11:29:43 »
asp.net webservice...

Sooo.... Windows or Linux? ASP on Mac/Linux via Mono has been more than viable for several years now.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #105 on: Tue, 25 February 2014, 19:43:09 »
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:

55625-0

55627-1

The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.

As you can see I'm an AZERTY user. The SpaceFN layout can be implemented on top of any national layout, be it an ANSI or ISO variant.

I have designed the keycaps by creating an SVG file (vector graphics) which has been sent to WASD Keyboards for printing. The legends have a better definition (resolution) than I expected.

The functions of the SpaceFN layer (activated by holding space) are written at the right of the keycaps, centered vertically.

Offline riotonthebay

  • Cherry Peasant
  • * Destiny Supporter
  • Posts: 2048
  • Location: Raleigh, NC
  • keycult.io
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #106 on: Tue, 25 February 2014, 19:46:36 »
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:

(Attachment Link)

(Attachment Link)

The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.

As you can see I'm an AZERTY user. The SpaceFN layout can be implemented on top of any national layout, be it an ANSI or ISO variant.

I have designed the keycaps by creating an SVG file (vector graphics) which has been sent to WASD Keyboards for printing. The legends have a better definition (resolution) than I expected.

The functions of the SpaceFN layer (activated by holding space) are written at the right of the keycaps, centered vertically.

This is the Right Way to use WASD's custom keycap offering, instead of the unicorn vomit more frequently seen.

Offline naasfu

  • The Curator
  • * Destiny Supporter
  • Posts: 3897
  • Location: april skies
  • WU-TANG IS FOR THE CHILDREN.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #107 on: Tue, 25 February 2014, 20:04:48 »
The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.
Nice keycaps. :)  My opinion is that they aren't needed since the SpaceFN layout is really quite intuitive. :)  Do you have custom firmware installed in that Poker, or are you using software like AHK?

I've been trying to use SpaceFN + lydell's AHK scripts for work for the past two weeks with both my Poker II and HHKB.  I really love the SpaceFN layout.  It is really intuitive and comfortable, and it's great that I can use it for any board. 

However, I'm having several issues with AHK that might be a deal breaker for me.  AHK doesn't work very well with Remote Desktop.  I have to exclusively run AHK on either my local box or remote box, but not both.  When typing remotely, the lag results in more timing issues than normal.  Also, I'm seeing an issue with my work machine where keypresses will be out of whack (Alt is permanently held down) after unlocking my machine.  Restarting the AHK script and even AHK does not fix the issue, and I'll have to relogin for things to work again.  I haven't had a chance to look into AHK's scripting, so maybe there are ways to address these issues.

I would love to have programmable firmware, but I don't know how to solder, and I would especially be afraid to mess with my HHKB, so this isn't an option for me right now.

You mentioned you are developing a new setup for Poker using its stock programming capabilities, so that will definitely be worth trying, although I won't be able to utilize this for my HHKB.

p.s.  Where is your red TEX case?  :p

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #108 on: Tue, 25 February 2014, 21:18:39 »
The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.
Nice keycaps. :)  My opinion is that they aren't needed since the SpaceFN layout is really quite intuitive. :)  Do you have custom firmware installed in that Poker, or are you using software like AHK?

I'm using KeyRemap4MacBook as this keyboard is connected to a Mac.


Quote
I've been trying to use SpaceFN + lydell's AHK scripts for work for the past two weeks with both my Poker II and HHKB.  I really love the SpaceFN layout.  It is really intuitive and comfortable, and it's great that I can use it for any board.

Yes. SpaceFN is comfortable, you use less energy when editing text, and it's less tiring for your hands and arms muscles.

Every time I go back to using a standard keyboard I can't help but notice how much I need to move my hands to reach the arrows.


Quote
However, I'm having several issues with AHK that might be a deal breaker for me.  AHK doesn't work very well with Remote Desktop.  I have to exclusively run AHK on either my local box or remote box, but not both.  When typing remotely, the lag results in more timing issues than normal.  Also, I'm seeing an issue with my work machine where keypresses will be out of whack (Alt is permanently held down) after unlocking my machine.  Restarting the AHK script and even AHK does not fix the issue, and I'll have to relogin for things to work again.  I haven't had a chance to look into AHK's scripting, so maybe there are ways to address these issues.

I would love to have programmable firmware, but I don't know how to solder, and I would especially be afraid to mess with my HHKB, so this isn't an option for me right now.

Yes these are problems with keyboard remapping software. It's not a "clean" solution.

For the HHKB, Hasu has created a specific PCB that replaces the HHKB's controller PCB (inside the HHKB there are 2 PCBs: one for the keyboard matrix, and one for the controller). If you had this PCB and its components already assembled, you could just swap it with your HHKB's controller, no soldering required, and it would turn your HHKB into a fully programmable keyboard (and you would lose the USB hub).


Quote
You mentioned you are developing a new setup for Poker using its stock programming capabilities, so that will definitely be worth trying, although I won't be able to utilize this for my HHKB.

Well, I'm not developing a layout for the Poker. I have developed a layout that is similar to SpaceFN but does not use space anymore, and it turns out that it can be programmed on the Poker 2. I started using this new layout on a Poker X and on an HHKB, then I have purchased a Poker 2 to test on it. It works perfectly on the Poker 2.

The motivation for creating this new layout is that using space as the Fn key meets to much psychological resistance. And for some people it really does not work. For example some apps require that you hold space to do some operations. Obviously this is not compatible with SpaceFN. I wanted to see if it was possible to retain some of the advantage of SpaceFN while at the same time eliminating these objections, and I think I have something interesting now.

I have actually already ordered a set of keycaps for this new layout because at this point I have been using it for more than one month and I believe it is stable. I have tried a number of permutations of keys and I think what I have now is the optimal arrangement, at least for me.


Quote
p.s.  Where is your red TEX case?  :p

In its box. I need to put the red case on the Poker 2 above. The blue case will go to the GH60. I think I'm going to wait for the new keycaps to do that.

Offline lydell

  • Posts: 42
  • Location: Sweden
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #109 on: Tue, 08 April 2014, 12:52:29 »
However, I'm having several issues with AHK that might be a deal breaker for me.  AHK doesn't work very well with Remote Desktop.  I have to exclusively run AHK on either my local box or remote box, but not both.  When typing remotely, the lag results in more timing issues than normal.

I’ve never used Remote Desktop, so unfortunately I cannot help.

Also, I'm seeing an issue with my work machine where keypresses will be out of whack (Alt is permanently held down) after unlocking my machine.  Restarting the AHK script and even AHK does not fix the issue, and I'll have to relogin for things to work again.  I haven't had a chance to look into AHK's scripting, so maybe there are ways to address these issues.

Modifiers that stick is a known problem. This is how I used to deal with that problem. I followed the steps in order until something worked:

1. Avoid situations that _always_ cause problems. This meant the “Unlock KeePass” shortcut and elevated command prompts for me. If a modifier still got stuck:
2. Press the `dual.reset()` shortcut. (Note: There is no such shortcut by default in spacefn-win; I advise you to add one.)
3. Kill the AHK script, then press each modifier once.
4. Log in and out or reboot :(

I’ve really tried to get to the bottom with this problem, but I haven’t been able to fix it totally. These days I’m not using Windows anymore, though, so don’t expect any progress. The AHK implementation is great for trying the layout out, and in my opinion it works quite well most of the time (at least it did for me). But as SpiceBar says, it is not a clean solution.

Offline admiralvorian

  • Posts: 324
  • Location: United States
  • DIY
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #110 on: Tue, 08 April 2014, 19:12:21 »
I've been running this for a while using ahk and I had to modify the timeout, it was too short on the original configuration. other than that it works great, preparing myself for a poker2
Darude Status:
☐ Not Sandstorm
☑ Sandstorm                                               wts wtt wtb

Offline berserkfan

  • Posts: 2136
  • Location: Not CONUS Not CONUS Not CONUS Not CONUS
  • changing diapers is more fun than model f assembly
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #111 on: Wed, 09 April 2014, 00:15:50 »
I've been running this for a while using ahk and I had to modify the timeout, it was too short on the original configuration. other than that it works great, preparing myself for a poker2

Just a general note from my experiences.

I am a big user of buckling springs and clears, so I am used to heavy springs. But when I tried using a cherry browns function key for a sustained period (holding it down to trigger my numpad layer created by autohotkey), I found it exhausting. And I was using a thumb used to heavier springs such as grays!

It looks like a sticky numlock works better if you need sustained used of the fn layer.
Most of the modding can be done on your own once you break through the psychological barriers.

Offline ideus

  • * Exalted Elder
  • Posts: 7578
  • Location: In the middle of nowhere.
  • Björkö.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #112 on: Wed, 09 April 2014, 08:47:26 »
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:

(Attachment Link)




(Attachment Link)

The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.

As you can see I'm an AZERTY user. The SpaceFN layout can be implemented on top of any national layout, be it an ANSI or ISO variant.

I have designed the keycaps by creating an SVG file (vector graphics) which has been sent to WASD Keyboards for printing. The legends have a better definition (resolution) than I expected.

The functions of the SpaceFN layer (activated by holding space) are written at the right of the keycaps, centered vertically.


So by dedicated keycaps you meant the customized ones you ordered from WASD K, didn't you? I was a little confused when I read a real space FN keyboard, because the entire point of Space-FN is precisely that any board can be used to implement it, so there is no such thing like a real FN board.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #113 on: Wed, 09 April 2014, 21:18:12 »
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:

(Attachment Link)




(Attachment Link)

The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.

As you can see I'm an AZERTY user. The SpaceFN layout can be implemented on top of any national layout, be it an ANSI or ISO variant.

I have designed the keycaps by creating an SVG file (vector graphics) which has been sent to WASD Keyboards for printing. The legends have a better definition (resolution) than I expected.

The functions of the SpaceFN layer (activated by holding space) are written at the right of the keycaps, centered vertically.


So by dedicated keycaps you meant the customized ones you ordered from WASD K, didn't you? I was a little confused when I read a real space FN keyboard, because the entire point of Space-FN is precisely that any board can be used to implement it, so there is no such thing like a real FN board.

By "real", I meant a keyboard with custom keycaps, so the SpaceFN layout is clearly visible on it.

The keyboard pictured does not even implement SpaceFN in hardware.  ;D

I have however at least 2 keyboards that implement SpaceFN in hardware, an HHKB and a GH60, and for them the dedicated keycaps make a lot of sense. Unfortunately, only the GH60 can use them.

Offline batfink

  • Posts: 57
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #114 on: Sun, 11 May 2014, 08:30:30 »
This SpaceFN idea is nice, it certainly makes better use of under-used thumbs.

It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/

Also for those who don't use left Alt much, this key has potential to be remapped to an Fn key as on most keyboards it can just about reached with the thumb. 

Does anyone have other suggestions/remappings for more efficient use of thumbs on a standard keyboard?
« Last Edit: Sun, 11 May 2014, 08:32:16 by batfink »

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #115 on: Mon, 12 May 2014, 04:29:30 »
This SpaceFN idea is nice, it certainly makes better use of under-used thumbs.

It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/

Also for those who don't use left Alt much, this key has potential to be remapped to an Fn key as on most keyboards it can just about reached with the thumb. 

Does anyone have other suggestions/remappings for more efficient use of thumbs on a standard keyboard?

This layout that I have also created and tested for a long time (still using it at this time) uses the right hand thumb to activate navigation keys:
  http://geekhack.org/index.php?topic=57723.0;topicseen

It is the brother of the SpaceFN layout.

Offline p3lim

  • Posts: 106
  • Location: Norway
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #116 on: Tue, 20 May 2014, 20:05:23 »
Made a version of my rebinder for windows in C# with this layout as a base, not exactly the same though. (can't use AHK, even packaged, anti-cheating software like PunkBuster bans anyone using it)
https://github.com/p3lim/Lackey/tree/SpaceFN

Not exactly sure if I like it yet, I feel like the spacebar lags out behind or something, mostly because I am used to type fast (100+ WPM), and the space comes in too late than what I am used to expect.
Really like how easy it is to use the FN layer though.
« Last Edit: Wed, 21 May 2014, 10:43:21 by p3lim »

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #117 on: Wed, 21 May 2014, 01:07:39 »
Made a version of my rebinder for windows in C# with this layout as a base, not exactly the same though. (can't use AHK, even packaged, anti-cheating software like PunkBuster bans anyone using it)
https://github.com/p3lim/Lackey/tree/SpaceFN

Not exactly sure if I like it yet, I feel like the spacebar lags out behind or something, mostly because I am used to type fast (100+ WPM), and the space comes in too late that what I am used to expect.
Really like how easy it is to use the FN layer though.

Nice job!

Offline Flamingchook

  • Posts: 278
  • Location: Australia
  • There are no dumb questions, only forbidden ones.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #118 on: Mon, 02 June 2014, 20:36:28 »
I've been using a slightly modified version of this layout on my Filco for a few weeks now. Implemented in firmware on a kitten paw controller. The delay on the spacebar was pretty distracting at first but I don't even notice it now.

Overall I'm really loving it. I'm training myself so hopefully I won't have any trouble adopting a full 60% layout when the GH60s finally arrive. :))
MX: Filco Majestouch Metalic Blue 104-key w/ MX Brown, JD40 w/ MX Green, ErgoDox w/ MX Blue, GHPad w/ MX Blue. Topre: Realforce 87U 45g. BS: IBM Model M 52G9700 29-OCT-93
Soon™: GH60 w/ 62g MX Clear, [CTRL]ALT 60 w/ MX Green

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #119 on: Mon, 02 June 2014, 21:48:50 »
I've been using a slightly modified version of this layout on my Filco for a few weeks now. Implemented in firmware on a kitten paw controller. The delay on the spacebar was pretty distracting at first but I don't even notice it now.

Overall I'm really loving it. I'm training myself so hopefully I won't have any trouble adopting a full 60% layout when the GH60s finally arrive. :))

Great.

Stay tuned, because I'm working on a slight improvement of SpaceFN based on my work on GuiFN.

The changes will be made available as a tmk firmware source code for the GH60 and other keyboards.

Don't worry, the changes are minor.

Offline quadibloc

  • Posts: 747
  • Location: Edmonton, Alberta, Canada
  • Layout Fanatic
    • John Savard's Home Page
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #120 on: Mon, 02 June 2014, 22:06:16 »
I agree that the space bar is too small on the Filco Minila. But having the space bar act funny scares me.

As it happens, I was doing some thinking ages ago of how to make a smaller keyboard like this. And I discuss what I came up with on my web site, at

http://www.quadibloc.com/comp/kyb0602.htm

Basically, I decided that there were two relatively little-used keys on the Model M typing area that were even in a symmetrical position, perfect for being repurposed as Fn keys.

The tab key, and the | and \ key.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #121 on: Tue, 03 June 2014, 13:45:16 »
I agree that the space bar is too small on the Filco Minila. But having the space bar act funny scares me.

As it happens, I was doing some thinking ages ago of how to make a smaller keyboard like this. And I discuss what I came up with on my web site, at

http://www.quadibloc.com/comp/kyb0602.htm

Basically, I decided that there were two relatively little-used keys on the Model M typing area that were even in a symmetrical position, perfect for being repurposed as Fn keys.

The tab key, and the | and \ key.

I think I had already seen your page some time ago, when I was doing research on keyboard layouts.

I'm not going to comment on all of your designs, as some are not relevant in the current context.

However one thing I have found with experience is that there is one finger that is not well suited for the Fn key, and one that is really a good choice.

The pinky should not be used for the Fn key. It's a weak finger that has very little mobility. While it may not be immediately noticeable, after a long work session it becomes obvious.

But there is one finger that is vastly underutilized and that is very well suited for the Fn key: it's the thumb. Depending on where you decide to put the arrow keys (these are the most used keys in the Fn layout in the context of a 60% keyboard), your thumb will already, naturally, fall on some key. This key is the best candidate for the Fn key.

If you put the arrows on IJKL or HJKL, as I did for SpaceFN, your thumb is already on Space. It becomes second nature to push on the thumb when you decide you want to navigate with the arrows. It's a no-brainer. You don't have to think about the location of the Fn key or reach for it with a weak finger.

The intriguing question was to find out is using Space as a Fn key would work or not. After months of using it, I can tell you it works very, very well.

If you are worried about using Space as the Fn key (which is a legitimate worry: for some applications overloading space is not an option), I have designed another layout called GuiFN that has the arrow keys located further on the right side so the thumb does not fall on Space this time.
  http://geekhack.org/index.php?topic=57723.msg1313182#msg1313182
This layout also works very well (I have also been using it for months: I eat my own dog food).

I know you love to design layouts yourself, so I thought you would also be interested by this one.

Offline quadibloc

  • Posts: 747
  • Location: Edmonton, Alberta, Canada
  • Layout Fanatic
    • John Savard's Home Page
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #122 on: Tue, 03 June 2014, 14:00:37 »
I have designed another layout called GuiFN
On that one, I'd probably use the pinky for the Fn, not the thumb. (How would I use the thumb for that Fn key without lifting the fingers of my right hand from the home keys?) And, of course, that is the layout (as far as the position of the Fn key goes) that is actually in use by the Poker II keyboard.

Since the pinky is already being used for Shift and Ctrl, I hadn't perceived that as an issue, although I'm not going to say your concern isn't valid. But if an appreciable portion of the keyboard is being used for shifted Fn-functions, one needs an Fn key for both hands.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #123 on: Tue, 03 June 2014, 17:59:36 »
I have designed another layout called GuiFN
On that one, I'd probably use the pinky for the Fn, not the thumb. (How would I use the thumb for that Fn key without lifting the fingers of my right hand from the home keys?) And, of course, that is the layout (as far as the position of the Fn key goes) that is actually in use by the Poker II keyboard.

It's important to note that GuiFN has not been designed with the Poker 2 in mind. It just happens to be compatible with it, and that's something I noticed well after designing it. I have purchased a Poker 2 one month after designing GuiFN and starting testing it on 3 other 60% boards.

Using the Fn key with the thumb is my design choice. It comes from my experience with SpaceFN, which helped me realize that pressing a Fn key with the thumb while the other fingers were on an inverted T arrow cluster was quite natural and easy to learn. If your pinky is pressing on a key, your other fingers have much less freedom, in particular for the kind of movements that we usually do when we use the arrow cluster.

The main goal of SpaceFN and GuiFN has never been to minimize hand travel. The goal was just to allow a 60% board to be as useable as a TKL. But if you consider hand travel, both SpaceFN and GuiFN end up being more efficient than a TKL or a standard full keyboard!

SpaceFN is the most efficient, as your hands almost don't move from the home position.

GuiFN has been created to answer to the objection of using space as a Fn key while keeping most of the advantages of SpaceFN, and it still manages to be more efficient than a standard keyboard, from the point of view of minimizing hand travel. If optimizing hand travel more comes at the cost of using the pinky, I prefer to keep on using the thumb and I give up on hand travel.


Quote
Since the pinky is already being used for Shift and Ctrl, I hadn't perceived that as an issue, although I'm not going to say your concern isn't valid. But if an appreciable portion of the keyboard is being used for shifted Fn-functions, one needs an Fn key for both hands.

With SpaceFN, obviously, you just need one Fn key.

With GuiFN, as you have probably noticed, all the secondary functions have been kept, as much as possible, on the right side. All these can be accessed with the right hand only, with the exception of the F1 to F6 keys and CapsLock.

I understand that you have an interest in designing layouts with the best possible arrangement, in absolute terms, and it's a very interesting process. You can just start with a clean slate and be as creative as you want.

I had to work with more stringent constraints: I start from an existing 60% layout where the number and sizes of the keys are already fixed. I try to leave the main layout as standard as possible, taking into account that many people (including me) already have muscle memory for all the characters-generating keys and most of the modifiers.

When you take this into account, it's already a little miracle to be able to come up with something that works. And that does not leave much freedom for an additional Fn key on the other side of the keyboard. :)

Offline Eszett

  • Posts: 490
  • Supporting the communities Geekhack & Deskthority
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #124 on: Wed, 02 July 2014, 22:00:37 »
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/
“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing all the time: type fast "A and B" and you will get "AAnd B"
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating

“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing that much. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.

“ReturnShift” is the most reasonably solution in my opinion, because:
1) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
2) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
3) It’s saving resources in that you will have one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have one additional key for your disposal.



« Last Edit: Wed, 02 July 2014, 22:08:36 by Eszett »

Offline swill

  • * Elevated Elder
  • Posts: 3359
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #125 on: Wed, 02 July 2014, 22:07:10 »
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/
“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing (type fast "A and B" and you will get "AAnd B")
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating

“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.

“ShiftReturn” is the most reasonably solution in my opinion, because:
1) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
2) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
3) You will get one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have 1 additional key for your disposal.

If it is only autorepeat that you are missing with SpaceFn, would you be able to map a repeating space key in the fn layer as a combined keypress?  Just thinking outloud here...

Offline Eszett

  • Posts: 490
  • Supporting the communities Geekhack & Deskthority
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #126 on: Wed, 02 July 2014, 22:27:38 »
... map a repeating space key in the fn layer as a combined keypress?
Sure, you could. But to invoke autorepeat by a key combination doesn’t seem very natural / intuitive for me. By intuition we know “hold down the key and autorepeat is what follows”. What do you think.

If it is only autorepeat that you are missing with SpaceFn ...
Well, doesn’t ReturnShift makes more sense, in that the key locations of the keyboard are more efficiently used? LeftShift and RightShift take up two key locations, for what, when you can have both in one location? The logic I like is: wed the most prominent key location to the most frequently used function.
« Last Edit: Wed, 02 July 2014, 22:47:25 by Eszett »

Offline swill

  • * Elevated Elder
  • Posts: 3359
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #127 on: Wed, 02 July 2014, 22:50:35 »
... map a repeating space key in the fn layer as a combined keypress?
Sure, you could. But to invoke autorepeat by a key combination doesn’t seem very natural / intuitive for me. By intuition we know “hold down the key and autorepeat is what follows”. What do you think swill.

If it is only autorepeat that you are missing with SpaceFn ...
Well, doesn’t ReturnShift makes more sense, in that the key locations of the keyboard are more efficiently used? LeftShift and RightShift take up two key locations, for what, when you can have both in one location?

I think it depends how you use shift. I almost always use shift in combination with my arrow keys for highlighting sections of code, so for me that has to be one of the most natural things.

If it is only the space key that autorepeat is hard with SpaceFn, I would have no problem using something like my right alt and space to act as my repeating space. Thats just me though.

Offline Justintoxicated

  • Posts: 158
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #128 on: Wed, 02 July 2014, 23:28:19 »
Not sure I like 60% due to my massive use of the arrow keys while navigating files.  On one hand once used to the 60% it might actually be faster since you do not have to leave home row, on the other hand its more work when just casually scrolling. 

Anyways at least Ctrl-Shift-Esc would work with this design unlike my FC600C :(

Offline hasu

  • Posts: 2967
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #129 on: Wed, 02 July 2014, 23:34:19 »
Good points, 'Dual role key' is all of trade off or compromise and which depends on your preference and typing habits. General discussion of 'Dual role key' will suit for this thread.
http://geekhack.org/index.php?topic=41685.0


It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/
“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing all the time: type fast "A and B" and you will get "AAnd B"
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating

“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing that much. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.

I saw that AHK script and have to say its implementation is too optimistic and naive for real usage of dual role key. That "AAnd B" problem is inevitable for dual role key intrisically but way better implementation can be existed. And you will be able to even optimize it accroding to your type fingering and speed. With the better and optimized dual role key you'll rarely see problems like that, but completely solution does not exists.
« Last Edit: Wed, 02 July 2014, 23:35:54 by hasu »
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #130 on: Wed, 02 July 2014, 23:50:22 »
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/
“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing (type fast "A and B" and you will get "AAnd B")
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating

“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.

“ShiftReturn” is the most reasonably solution in my opinion, because:
1) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
2) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
3) You will get one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have 1 additional key for your disposal.

If it is only autorepeat that you are missing with SpaceFn, would you be able to map a repeating space key in the fn layer as a combined keypress?  Just thinking outloud here...

You are trying to find solutions for a problem that is already solved in SpaceFN. :)

1. Fn-B  ("Blank") does space. It autorepeats. This works in all implementations of SpaceFN.

2. Double-tapping space is also an autorepeating space, but it works only if you are using the SpaceFN version of TMK firmware.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #131 on: Wed, 02 July 2014, 23:57:03 »
Not sure I like 60% due to my massive use of the arrow keys while navigating files.  On one hand once used to the 60% it might actually be faster since you do not have to leave home row, on the other hand its more work when just casually scrolling. 

Anyways at least Ctrl-Shift-Esc would work with this design unlike my FC600C :(

I can confirm that with SpaceFN you don't leave the home row and that using the arrows is much less tiring than on a standard or TKL keyboard. It's one of the things that shocked me the most after using SpaceFN exclusively for three months when I returned on a TKL. I suddenly realized that on a standard keyboard I had to move my hands all around when switching from typing to selecting, and the additional expense of energy was suddenly obvious.

The funny thing is that SpaceFN had not been designed to minimize hand travel. But it just does.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #132 on: Thu, 03 July 2014, 00:09:39 »
Good points, 'Dual role key' is all of trade off or compromise and which depends on your preference and typing habits. General discussion of 'Dual role key' will suit for this thread.
http://geekhack.org/index.php?topic=41685.0


It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/
“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing all the time: type fast "A and B" and you will get "AAnd B"
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating

“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing that much. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.

I saw that AHK script and have to say its implementation is too optimistic and naive for real usage of dual role key. That "AAnd B" problem is inevitable for dual role key intrisically but way better implementation can be existed. And you will be able to even optimize it accroding to your type fingering and speed. With the better and optimized dual role key you'll rarely see problems like that, but completely solution does not exists.

The real surprise, when I first tried SpaceFN implemented in your firmware, is that I almost never have a problem with space being misinterpreted. And I did not try to optimize any setting. I just did not have to.

I think that for most people SpaceFN just works. It may be unsuitable for some for other reasons, but not because space is going to be misinterpreted, at least not until your reach speeds above 100-120 WPM.

I have not been able to try the AHK script, because I don't have any Windows computer. On the other hand the KeyRemap4MacBook script never makes any mistake, because it has a rather long timeout. The downside is that you need to press and hold space for a split of a second before you can use the Fn layer. But while typing text, as fast as you want, it cannot trigger a Fn action. It's the opposite actually: you would have to type extremely slowly and leave your thumb on space for too long to trigger an unwanted Fn action.

Offline davkol

  •  Post Editing Timeout
  • Posts: 4994
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #133 on: Thu, 03 July 2014, 02:46:48 »
“ReturnShift” is the most reasonably solution in my opinion, because:
1) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
2) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
3) It’s saving resources in that you will have one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have one additional key for your disposal.
It can be *VERY* dangerous though. Imagine the conversion to Shift fails, when you're doing something in CLI. It can be a disaster.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #134 on: Thu, 03 July 2014, 03:11:47 »
“ReturnShift” is the most reasonably solution in my opinion, because:
1) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
2) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
3) It’s saving resources in that you will have one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have one additional key for your disposal.
It can be *VERY* dangerous though. Imagine the conversion to Shift fails, when you're doing something in CLI. It can be a disaster.

Yes. People already believe that using space as a dual-role modifier is dangerous, so what are they going to think about Enter!?

I do believe using Enter as a dual-role Shift is dangerous. I would probably avoid using Enter, Backspace or Tab as dual-role modifiers.

Also, Enter is not so easily reachable on ISO keyboards.

Offline Eszett

  • Posts: 490
  • Supporting the communities Geekhack & Deskthority
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #135 on: Thu, 03 July 2014, 12:11:21 »
Quote
It can be *VERY* dangerous though. Imagine the conversion to Shift fails, when you're doing something in CLI. It can be a disaster.

Do I understand your argument right, you say ShiftReturn increases the chance of
triggering return by mistake (by lax typing), which can be a mess in certain situations?

Offline scottjad

  • Posts: 10
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #136 on: Tue, 23 September 2014, 23:14:02 »
Has anyone looked at adding SpaceFN to the usb_usb tmk converter?

This seems like a really attractive option because it would allow anyone to add the (supposedly) best implementation of SpaceFN to their keyboard for $22 shipped (Leonardo Arduino and USB host on eBay) and without any soldering decide whether they liked the layout. This seems like a really nice option even if some advanced keyboard options (I'm not sure exactly which) don't work with the usb_usb converter.

Unfortunately I don't know enough C to be able tell how easily the SpaceFN keymap from other directories in TMK [1] could be added to the usb_usb converter directory [2]. It appears that it might have fallen out of sync with the rest of TMK and need to be updated. Anyone familiar enough with C to see what's needed?

[1] https://github.com/tmk/tmk_keyboard/blob/master/converter/ps2_usb/keymap_spacefn.c
[2] https://github.com/tmk/tmk_keyboard/tree/master/converter/usb_usb

Thanks,
Scott
Current: RF 87U 45g, Keycool 84 White w/ Browns, Noppoo Choc Mini Black w/ Browns, Thinkpad X220

Sold: RF 87U Ergo, TEX Beetle w/ Blues, Noppoo Choc Mini Black w/ Reds, Truly Ergonomic w/ Browns, Kinesis Advantage, Kinesis Freestyle, TypeMatrix, Das Keyboard w/ Blues

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #137 on: Fri, 03 October 2014, 02:34:55 »
Has anyone looked at adding SpaceFN to the usb_usb tmk converter?

This seems like a really attractive option because it would allow anyone to add the (supposedly) best implementation of SpaceFN to their keyboard for $22 shipped (Leonardo Arduino and USB host on eBay) and without any soldering decide whether they liked the layout. This seems like a really nice option even if some advanced keyboard options (I'm not sure exactly which) don't work with the usb_usb converter.

Unfortunately I don't know enough C to be able tell how easily the SpaceFN keymap from other directories in TMK [1] could be added to the usb_usb converter directory [2]. It appears that it might have fallen out of sync with the rest of TMK and need to be updated. Anyone familiar enough with C to see what's needed?

[1] https://github.com/tmk/tmk_keyboard/blob/master/converter/ps2_usb/keymap_spacefn.c
[2] https://github.com/tmk/tmk_keyboard/tree/master/converter/usb_usb

Thanks,
Scott

I don't know if Hasu could help us with this, but it sure would be nice to have a USB to USB TMK converter. I own several PS/2 to USB converters he has made which are quite useful, but they are a few keyboards they don't work with.

Examples are: the RF87, the Poker 2 and the FC660C. These are USB only keyboards. They are not PS/2 compatible, so the TMK converters do not work with them.

They don't work either with the HHKB, but he has created a dedicated fully programmable replacement controller card for the HHKB that works perfectly. Great work.

A USB to USB converter would be almost universal (it wouldn't work on keyboards that act as USB hubs, and on keyboards that do NKRO over USB, but there aren't too many of them anyway).

I seem to remember I have seen something about USB to USB conversion with the TMK firmware, but it was either not complete or required a different hardware than the one Hasu uses. It was several months ago, so I don't remember clearly what the problem was. I think the USB protocol had to be emulated for one of the USB ports, because the dedicated USB controller was used for the other port, so basically it was a USB software emulation and that was not easy to do and pushed the controller to its limits. The solution is to have a controller or some hardware extension that provides two real hardware USB ports. And the software part to drive the second USB port naturally.

An USB to USB TMK converter would be hot stuff, especially if it's small enough to be hidden inside a keyboard's case.

Offline jacobolus

  • Posts: 3642
  • Location: San Francisco, CA
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #138 on: Fri, 03 October 2014, 02:35:56 »

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #139 on: Fri, 03 October 2014, 03:02:16 »
Has anyone looked at adding SpaceFN to the usb_usb tmk converter?

This seems like a really attractive option because it would allow anyone to add the (supposedly) best implementation of SpaceFN to their keyboard for $22 shipped (Leonardo Arduino and USB host on eBay) and without any soldering decide whether they liked the layout. This seems like a really nice option even if some advanced keyboard options (I'm not sure exactly which) don't work with the usb_usb converter.

Unfortunately I don't know enough C to be able tell how easily the SpaceFN keymap from other directories in TMK [1] could be added to the usb_usb converter directory [2]. It appears that it might have fallen out of sync with the rest of TMK and need to be updated. Anyone familiar enough with C to see what's needed?

[1] https://github.com/tmk/tmk_keyboard/blob/master/converter/ps2_usb/keymap_spacefn.c
[2] https://github.com/tmk/tmk_keyboard/tree/master/converter/usb_usb

Thanks,
Scott

OK, it looks like I should have read your post more carefully, as you have already found much of the relevant information.

So it looks like a hardware expansion is indeed necessary, in order to add a USB host to the converter. This should take care of the connection between the keyboard and the converter. The converter then uses the build-in USB port to send (and receive) data from the computer.

I cannot say anything about the state of the TMK software in this configuration, except that Hasu says that it is experimental. So it must have some unfixed issues at this time, or it simply has not been tested enough.

I don't think the keymap_spacefn.c file would be the problem. This file essentially defines two data arrays that are used by the firmware to associate received scancodes to scancodes that must be output. If the TMK software, as modified to drive the USB-USB converter, is still basically the same at its core, the keymap_spacefn.c file should work as it is.

Do you know a little bit about the Leonardo Arduino and the USB host? Does the host simply piggyback on the main board? Does it have to be soldered? What is the width of the assembly? I'm trying to find out if we could easily fit this stuff inside a keyboard case, assuming we can get it to work.



Offline scottjad

  • Posts: 10
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #140 on: Sun, 05 October 2014, 23:05:31 »

I don't think the keymap_spacefn.c file would be the problem. This file essentially defines two data arrays that are used by the firmware to associate received scancodes to scancodes that must be output. If the TMK software, as modified to drive the USB-USB converter, is still basically the same at its core, the keymap_spacefn.c file should work as it is.

Do you know a little bit about the Leonardo Arduino and the USB host? Does the host simply piggyback on the main board? Does it have to be soldered? What is the width of the assembly? I'm trying to find out if we could easily fit this stuff inside a keyboard case, assuming we can get it to work.

I don't know anything about the Leonardo Arduino and USB host on a technical level. I did buy both on eBay, before looking closely at the TMK firmware, and with shipping to US included and a microUSB->USB cable they go for $22. There is no soldering required, you basically plug them together, which took me a minute because I was really cautious but it could be done in five seconds. It is way too big to fit in a keyboard case, at least of any keyboard that I've ever seen. It is 1.125"x2.125"x2.75". I see it sitting on my desk behind my computer in a small box (when I run into a product with the right dimensions). So no good for a portable setup, but perfectly fine for testing out SpaceFN or a desktop setup. You plug your USB keyboard into the USB host and you plug the microUSB->USB cable that came with the Leonardo into your computer. I think we could have TMK firmware precompiled with SpaceFN so placing that firmware on the Leonardo could be a few more minutes.

The USB->USB TMK firmware is limited to HID mode and from what I gather would require quite some work to overcome this. Unfortunately I don't really know what exactly the limitations of HID mode are. I gather it prevents using keys as a mouse but I'm not sure if it also means media keys don't work or what else. If it's only mouse and media keys that don't work, I think this is fine, since I see this really as being an easy and affordable way for people to see if they like SpaceFN with a good implementation of the software. If they decide they like it then they go put in the extra money and time to come up with a better solution.

As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)

edit: it's microUSB not miniUSB.
« Last Edit: Mon, 06 October 2014, 14:11:42 by scottjad »
Current: RF 87U 45g, Keycool 84 White w/ Browns, Noppoo Choc Mini Black w/ Browns, Thinkpad X220

Sold: RF 87U Ergo, TEX Beetle w/ Blues, Noppoo Choc Mini Black w/ Reds, Truly Ergonomic w/ Browns, Kinesis Advantage, Kinesis Freestyle, TypeMatrix, Das Keyboard w/ Blues

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #141 on: Mon, 06 October 2014, 02:54:59 »

I don't think the keymap_spacefn.c file would be the problem. This file essentially defines two data arrays that are used by the firmware to associate received scancodes to scancodes that must be output. If the TMK software, as modified to drive the USB-USB converter, is still basically the same at its core, the keymap_spacefn.c file should work as it is.

Do you know a little bit about the Leonardo Arduino and the USB host? Does the host simply piggyback on the main board? Does it have to be soldered? What is the width of the assembly? I'm trying to find out if we could easily fit this stuff inside a keyboard case, assuming we can get it to work.

I don't know anything about the Leonardo Arduino and USB host on a technical level. I did buy both on eBay, before looking closely at the TMK firmware, and with shipping to US included and a miniUSB->USB cable they go for $22. There is no soldering required, you basically plug them together, which took me a minute because I was really cautious but it could be done in five seconds. It is way too big to fit in a keyboard case, at least of any keyboard that I've ever seen. It is 1.125"x2.125"x2.75". I see it sitting on my desk behind my computer in a small box (when I run into a product with the right dimensions). So no good for a portable setup, but perfectly fine for testing out SpaceFN or a desktop setup. You plug your USB keyboard into the USB host and you plug the miniUSB->USB cable that came with the Leonardo into your computer. I think we could have TMK firmware precompiled with SpaceFN so placing that firmware on the Leonardo could be a few more minutes.

The USB->USB TMK firmware is limited to HID mode and from what I gather would require quite some work to overcome this. Unfortunately I don't really know what exactly the limitations of HID mode are. I gather it prevents using keys as a mouse but I'm not sure if it also means media keys don't work or what else. If it's only mouse and media keys that don't work, I think this is fine, since I see this really as being an easy and affordable way for people to see if they like SpaceFN with a good implementation of the software. If they decide they like it then they go put in the extra money and time to come up with a better solution.

As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)

You did well.

I'm very interested in this USB->USB converter because I own a few PS2->USB ones, which do not work with USB only keyboards. And I would like to convert some of these keyboards to SpaceFN.

I'm the author of SpaceFN and I'm fluent in C, but I do not know the TMK firmware very well. Also, I do not have the required hardware yet (the Arduino and the USB host), and I do not have much time at the moment.

I need to order the hardware and spend some time with it.

Also, we may need Hasu to help us a little bit. If he doesn't read this, I'll send him an email.

I'm not 100% sure, but I think HID mode is enough for SpaceFN. I think the media keys just send scancodes, so HID mode should not be a problem. Mouse mode will probably be a problem.

Now I need a way to get the hardware, which may not be easy as I don't live in the US.

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #142 on: Mon, 06 October 2014, 04:55:24 »
OK, I just ordered the Arduino Leonardo and the USB host shield 2.0.

I guess they will take 7 to 10 days to be delivered. The Arduino will be shipped by Fedex, so I expect it for the end of the week, but the USB host is shipping with AirMail. This will take more time.

When I receive them I try to compile the TMK firmware and the SpaceFN layout for it.

I want SpaceFN to work on this USB->USB "adapter".

Offline hasu

  • Posts: 2967
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #143 on: Mon, 06 October 2014, 20:49:46 »
As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)

edit: it's microUSB not miniUSB.

It worked? Great!
Very good indication for reviving long dead project :D

Yes, keymap of the converter is defined in old 'legacy' notation. But I think you can port SpaceFN keymap from ps2_usb converter with reading this doc. If you have questions about this post my thread.
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#5-legacy-keymap
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #144 on: Tue, 07 October 2014, 05:37:16 »
As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)

edit: it's microUSB not miniUSB.

It worked? Great!
Very good indication for reviving long dead project :D

Yes, keymap of the converter is defined in old 'legacy' notation. But I think you can port SpaceFN keymap from ps2_usb converter with reading this doc. If you have questions about this post my thread.
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#5-legacy-keymap

It's unfortunate that the USB->USB converter uses the legacy notation, because I have recently enhanced the SpaceFN layout to support some goodies from the GuiFN layout, and added optional shortcuts for PgUp and PgDn with the arrow keys (Space-I and Space-J).

But maybe it will not be too hard to adapt to the legacy notation. I'm going to have a good look at it when I receive the hardware.

Yes, maybe it's time to revive the project, because it looks like the hardware needed to make it work is widely available at a reasonable price (even if it's a little bulky at this time), and most keyboards are now giving up on PS/2 support.

Offline yasuo

  • Posts: 976
  • Location: ID
  • spanengan puyeng newbie
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #145 on: Tue, 07 October 2014, 08:00:24 »
may bad queston
this is effective in ergdox/split keyboard?
Logitech MK220 Colemak DH
SplitSyml by Moz BlacksMx fuk blacks

2/3 8.5pm                                          in de la my september month ya da all get my fukka "fake message"

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #146 on: Tue, 07 October 2014, 08:39:05 »
may bad queston
this is effective in ergdox/split keyboard?

I don't remember anyone reporting they have tried SpaceFN on an Ergodox.

I think it should work. I can see no reason it would not work. And it would not be hard to do, as the TMK firmware works with the Ergodox.

Offline argcargv

  • tempting the banhammer
  • Posts: 188
  • Location: michigan
  • PERSONAL TEXT NUKED BY STATIONARY WARHEAD
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #147 on: Tue, 07 October 2014, 10:12:32 »
I love spaceFN  :thumb:
MOD EDIT -- NUKED FROM ORBIT

Offline samwisekoi

  • MAWG since 1997
  • * Administrator
  • Posts: 2480
  • Location: Mt. View, California
  • Sorry, moving houses. Be back ASAP.
    • Tweet samwisekoi
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #148 on: Tue, 07 October 2014, 10:48:34 »
[WARNING: Intentional cross-post below]

I've been watching this thread off and on since it popped up.  My interest is more in custom hardware than software, and (sadly) I am not a touch-typist, so SpaceFN is not for me.  But it is interesting, and I have spent much time experimenting with both sub-TKL keyboards and FN-key placement.

But one of my recent projects is the GH36 programmable matrix keypad.  I have arthritis in my thumbs, so I use the keypad for ergonomic reasons as a LH half-keyboard for keyboard-and-mouse gaming.  But others have seen the potential for using a pair of GH36 keypads connected to make a much lower-cost split ergonomic keyboard.  (You can see an example in the GH36 thread.)

But this morning as I was reading the latest SpaceFN posts, it struck me that SpaceFN + one GH36 could result in a keyboard useable by people with only one hand.  Tap the 2x-wide "spacebar" for a space; hold it to swap keyboard sides left-to-right.  So...

qwert + spacebar = yuiop
12345 + spacebar = 67890


Someone with more neurology than I (or a missing hand) would have to say if the FN layer should be mirrored or not.  Perhaps if a person used to touch-type and now doesn't, the remaining ring finger should be both s and l.  And for someone without touch typing, the LH ring finger should be s and k (second from left) because that would make the printed keymap seem more standard.

Anyhow, just a thought.  Would half of a SpaceFN keyboard be a valuable aid to someone who (e.g.) came home from military service with fewer hands?

If there is someone who would be interested in experimenting with this concept, I'd happily donate some hardware.

 - Ron | samwisekoi
Sig auto-typed by my GH36 LH keypad.
I like keyboards and case modding.  Everything about a computer should be silent -- except the KEYBOARD!

'85 IBM F-122/Soarer Keyboard |  Leopold FC200 TKL (Browns) + GH36 Keypad (Browns/Greens) | GH-122 (Whites/Greens) with Nuclear Data Green keycaps in a Unicomp case

Offline spiceBar

  • Thread Starter
  • Posts: 997
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #149 on: Tue, 07 October 2014, 11:47:58 »
[WARNING: Intentional cross-post below]

I've been watching this thread off and on since it popped up.  My interest is more in custom hardware than software, and (sadly) I am not a touch-typist, so SpaceFN is not for me.  But it is interesting, and I have spent much time experimenting with both sub-TKL keyboards and FN-key placement.

But one of my recent projects is the GH36 programmable matrix keypad.  I have arthritis in my thumbs, so I use the keypad for ergonomic reasons as a LH half-keyboard for keyboard-and-mouse gaming.  But others have seen the potential for using a pair of GH36 keypads connected to make a much lower-cost split ergonomic keyboard.  (You can see an example in the GH36 thread.)

But this morning as I was reading the latest SpaceFN posts, it struck me that SpaceFN + one GH36 could result in a keyboard useable by people with only one hand.  Tap the 2x-wide "spacebar" for a space; hold it to swap keyboard sides left-to-right.  So...

qwert + spacebar = yuiop
12345 + spacebar = 67890


Someone with more neurology than I (or a missing hand) would have to say if the FN layer should be mirrored or not.  Perhaps if a person used to touch-type and now doesn't, the remaining ring finger should be both s and l.  And for someone without touch typing, the LH ring finger should be s and k (second from left) because that would make the printed keymap seem more standard.

Anyhow, just a thought.  Would half of a SpaceFN keyboard be a valuable aid to someone who (e.g.) came home from military service with fewer hands?

If there is someone who would be interested in experimenting with this concept, I'd happily donate some hardware.

 - Ron | samwisekoi
Sig auto-typed by my GH36 LH keypad.

Good ideas never die!
  http://www.keyboardco.com/keyboard/matias-half-keyboard-single-handed-keyboard.asp
  http://www.keyboardco.com/keyboard/matias-half-qwerty-508-keyboard.asp

All credit goes to Matias, who actually pointed out earlier to me that he had worked on the idea of space as a dual-role modifier a long time ago.


PS: SpaceFN is not reserved to touch-typists. I don't consider myself a touch-typist. SpaceFN has just been designed initially with the goal of being a usable layout for 60% keyboards. It's true that touch-typists may find SpaceFN advantageous, but it's not hard to learn and works for all kinds of people.
« Last Edit: Tue, 07 October 2014, 11:52:32 by spiceBar »