Author Topic: ErgoDox - Custom split ergo keyboard.  (Read 1238013 times)

0 Members and 2 Guests are viewing this topic.

Offline ic07

  • Posts: 190
[Interest Check] Custom split ergo keyboard.
« Reply #700 on: Mon, 04 June 2012, 14:21:32 »
OrangeJewce, effh, you guys are awesome.

  Modifying the hex is a good idea.  The only complication I can see is that layer switching is done by putting a different function for that key's location in the `_kb_layout_press` and `_kb_layout_release` matricies (see qwerty.c in 'dev' for an example).

  Allocating enough space for all the layers you want should only mean changing the value of `KB_LAYERS` in qwerty.h before compile.  Unused layers won't confuse anything.


  For anyone trying to understand the layout, take a look at:

  - qwerty.h for the macro defining the number of layers, and the mapping from physical LED position to the meaning of the LEDs
  - qwerty.c for the keycodes, key press functions, and key release functions assigned to each physical key position
  - and usb/usage-page/keyboard--short-names.h for all availble keycodes (or usb/usage-page/keyboard.h for the actual hex codes)

  Those three files should contain everything you need.  If you want more information, you can look at:

  - matrix.h for a more thorough description of the `LAYER()` macro used in 'qwerty.c', and what it's doing
  - and if you really want to get into it, key-functions.c is where the functions called for each key(press|release) are defined; you might have to poke through the PJRC USB code (in src/lib-other/...) to understand parts though

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #701 on: Mon, 04 June 2012, 15:01:26 »
ic07,

     My thinking is that when you switch layers, the keyboard is using a different section of the compiled .hex to do the mapping. Therfore I would expect that we should still be able to directly hack our way through the compiled .hex to alter the key-mappings for each layer.

Going the GUI route would mean we might have to make some sacrifices if we choose not to recompile the firmware. My plan is to only offer the number of layers officially coded into the firmware source, so that would be 2 right now. However, if a user really wants more layers, then they can always edit the default.hex by replacing it with one of their own or by compiling the source.

effh,

     I am concerned about the checksum issue. Are you sure that the teensy will refuse to accept updates if a modification is made to the .hex without generating new checksums? If that's the case we probably won't have any choice but to force a compile of the firmware source.

Cheers,

OJ
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline Dox

  • Thread Starter
  • Posts: 312
[Interest Check] Custom split ergo keyboard.
« Reply #702 on: Mon, 04 June 2012, 17:41:36 »
OrangeJewce and effh, good ideas for the remapping, keep it up!

Quote from: OrangeJewce;607145
Also,

DOX, do you have a larger version of your avatar? I plan on using it for the About menu on the GUI, as well as making a .ico to use for the launcher. (Assuming you guys don't mind me writing up a front-end.)

Cheers,
Post 17 here. Thanks to calavera.


ic07, I think there is a bug with the fn layer. I used the prototype all day at work and sometimes, the fn layer becomes inaccessible after some use.
Otherwise, everything went well. With the thumb keys a bit closer, it will be perfect! I already prefer it to the kinesis. With the flat shape, it gives me more freedom when I need it and the ability to place each hand in the optimal position is really great.
ErgoDox x2 | DoxKB x2 |   IBM SSK   | HHKB pro2

Offline effh

  • Posts: 6
[Interest Check] Custom split ergo keyboard.
« Reply #703 on: Mon, 04 June 2012, 18:59:33 »
OrangeJewce,

No, I'm not that concerned about there being an aditional checksum, that would be an extra-work feature that would have required cooperation between teensy and winAVR or an extra added by ic07 (which hasn't been mentioned, so hasn't happened.) so it is a low probability.
With regards to switching sections of the compiled hex, all layers have been implemented as part of the same array and are contiguous.

The map I have here was built off of the dev tree and states that _kb_layout starts at 0x00ac, the next symbol being at 0x0154. that is 168 bytes.
The layer macro defines 84 bytes of data per layer, 168/84 is 2.  Coincidentally, thats the number of layers currently in the dev-branch, so we've found all the keymap definitions. (though I've not fully explained to my satisfaction _kb_layout_press and _kb_layout_release. erg. Now I have. _kb_layout is of type uint8_t, the other two is of type kbfun_funptr_t (pointer to function). effective but fun to handle. Examination shows repetition at 16-bit intervals. But not of a sequence that ties up to the map's definition of the functions I was expecting. I'll do some more digging later when it isn't approching 0100.
Update: The value stored in the press and release tables is the "word address" of the function in flash, while the map has the "byte address". the byte address from the map divided by 2 gives the value in the table. Note that the avr is a little endian device, so an address of 0x0b7e divided by two is 0x05bf and would appear in the .hex as bf05.

Summary:
#1: Don't worry about checksums, we'll cross that bridge if we meet it.
#2: We also know now where all the keymapping is, even if we don't know the right values for the press and release functions yet.
#3: Values of positions will change on each compile, so if we can work out how to extract the values programatically from the map, that would be best.

ic07,

The definition of the Layer macro is the fundamental mapping of what keys are where in the array, so that is going to be critical :  )
So far, so good.

Sorry about any typos, dyslexia and late nights don't mix.
« Last Edit: Mon, 04 June 2012, 20:15:11 by effh »

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #704 on: Mon, 04 June 2012, 19:39:59 »
effh,

     Thanks for the clarification. I am working on the prototype GUI right now. I have all 76 buttons created, but have yet to implement the back end. Obviously that will take the longest to do, as I still don't really have a grasp as to how the firmware is going to work. For anyone interested I have forked off the git and made a UI branch. It is a WinForms project (It's just too easy for this kind of thing. Might upgrade to WPF later) in C#. I make a pull request later this evening. No ETA as of yet on how long this UI project will take, I presume there is at least a little time before we have a fully assembled prototype in Dox's Hands.

Cheers,
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline effh

  • Posts: 6
[Interest Check] Custom split ergo keyboard.
« Reply #705 on: Mon, 04 June 2012, 20:32:07 »
OrangeJewce,

If we can agree a simple (that means not xml) file interchange format, I can probably do a cut of code (c++ as for cross-platform usage and reduced writing time) that would modify the map in a hex-file/map pair.
I'm thinking something like:
Code: [Select]
:_kb_layout{lf}
ababababababababababababababab{lf}
:_kb_layout_press{lf}
111111121111113111111411111{lf}
:_kb_layout_release{lf}
111111121111113111111411111{lf}
where ab is a byte represented in ascii, 1 2 3 and 4 are press, release, layer increment and layer decrement and {lf} is a linefeed character (0x0a in the table)
I can also set up options to allow getting the number of layers in the map from the map. (based on size of allocation.)

Thoughts?

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #706 on: Mon, 04 June 2012, 20:45:41 »
effh,

     That sounds great!

Cheers,

OJ
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline ic07

  • Posts: 190
[Interest Check] Custom split ergo keyboard.
« Reply #707 on: Tue, 05 June 2012, 15:16:16 »
Quote from: Dox;607456
ic07, I think there is a bug with the fn layer. I used the prototype all day at work and sometimes, the fn layer becomes inaccessible after some use.

I looked at the logic again last night, and it still looks right to me...  Do you have any ideas?  Or at least, in laborious detail, what exactly's happening (maybe this calls for a PM) lol :) .  Sorry you have to help debugging stuff I wrote, but I can't think of a way to test it myself... :/ .  If *any* keys are registering, those should be working too...  I suppose, worst case, I can try to start rewriting the thing next week.

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #708 on: Tue, 05 June 2012, 15:39:39 »
Quote from: ic07;608033
I looked at the logic again last night, and it still looks right to me...  Do you have any ideas?  Or at least, in laborious detail, what exactly's happening (maybe this calls for a PM) lol :) .  Sorry you have to help debugging stuff I wrote, but I can't think of a way to test it myself... :/ .  If *any* keys are registering, those should be working too...  I suppose, worst case, I can try to start rewriting the thing next week.

ic07,

     It would be helpful if we can keep changes to the backend to a minimum (outside of bug fixes like this), since effh & I will be relying on consistency there to create a usable GUI. Though we'll be hacking the compiled hex directly, it would be nice to be able to know that recompilation we do will give us consistent results. I am having a hard time following what's going on in main.c, in the innermost for loop. Where do you specify a switching between layers?

Cheers,
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #709 on: Tue, 05 June 2012, 15:47:12 »
ic07,

     follow up: main.c is missing an include in the repo: . Can you add that?

Cheers,
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline bebuxe

  • Posts: 146
[Interest Check] Custom split ergo keyboard.
« Reply #710 on: Tue, 05 June 2012, 17:48:30 »
>ic07
Thanks, that is exactly what I was talking about. Will make more /layout/ later, after I clean my apartment. I guess remapping will be the way to go here then at the OS level then.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
[Interest Check] Custom split ergo keyboard.
« Reply #711 on: Tue, 05 June 2012, 18:21:12 »
Yep, the possibility of HW remapping is one of the best features for me.

Offline effh

  • Posts: 6
[Interest Check] Custom split ergo keyboard.
« Reply #712 on: Wed, 06 June 2012, 01:28:09 »
Quote from: OrangeJewce;608049
ic07,

     It would be helpful if we can keep changes to the backend to a minimum (outside of bug fixes like this), since effh & I will be relying on consistency there to create a usable GUI. Though we'll be hacking the compiled hex directly, it would be nice to be able to know that recompilation we do will give us consistent results. I am having a hard time following what's going on in main.c, in the innermost for loop. Where do you specify a switching between layers?

Cheers,


I'm going to have to counter that. For starters, I suspect a couple of changes will be necessary to support 3+ layers.

ic07, Make any changes you need/want to make, just keep the layout in a nice sensible array/set of arrays in "progmem". (I need to look up the details of that sometime :  )

At some point, it would make OrangeJewce's life easier if one of us could detail the order of keys in the array when expressed as flat memory, as that is the order I'll be needing the data in to in-fill the hex file.

To reiterate: so-long as _kb_layout, _kb_layout_press and _kb_layout_release don't change their definitions (and the functions used in _kb_layout_ don't change name and number), and that a map file has been built along with the hex file, what I have in mind should continue to work. Changes to those will require some degree of rework and thus notification of changes to them would be appreciated.
Generic Solutions for the win :  )

Offline ic07

  • Posts: 190
[Interest Check] Custom split ergo keyboard.
« Reply #713 on: Wed, 06 June 2012, 14:06:07 »
Quote from: OrangeJewce;608049
I am having a hard time following what's going on in main.c, in the innermost for loop. Where do you specify a switching between layers?


  The innermost loop in main.c is *only* responsible for calling the appropriate function (assigned to each key in the layout matrices, and defined in lib/key-functions.c), and then calling usb_keyboard_send() if necessary.  Everything else is done by the key function - so layer switching (changing the value of the current_layer variable at the top of the outer main() loop) is actually done in lib/key-functions.c::kbfun_layer_inc() and lib/key-functions.c::kbfun_layer_dec().

 
Quote from: OrangeJewce;608058
follow up: main.c is missing an include in the repo: . Can you add that?


  is part of avr-libc.  And the #include is in main.c in every branch I checked (though, I did forget it a few commits ago, when I committed -> pushed without trying to compile first - which wasn't very smart of me, lol).

 
Quote from: effh;608373
ic07, Make any changes you need/want to make, just keep the layout in a nice sensible array/set of arrays in "progmem". (I need to look up the details of that sometime :  )


  :) .  I don't anticipate changing how the _kb_layout* matrices are defined unless I really really (really) have to.  And the kbfun_*() functions used in _kb_layout_ shouldn't be changing much either (though, I'm not sure what you mean by "name and number"; but their names shouldn't change, and I won't remove any).  I'll do my best to let you guys know if I start messing with stuff that I think might affect you.

As a side note, having the layout matrices in PROGMEM is not guaranteed by the current design (it's the default, but it can be changed per layout).  I'm not planning to put any anywhere else though, since RAM only has enough space for ~2 layers IIRC, the EEPROM is even smaller, and the extra time/code it takes to have stuff in PROGMEM appears to be inconsequential.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
[Interest Check] Custom split ergo keyboard.
« Reply #714 on: Wed, 06 June 2012, 17:38:01 »
I'm interested in learning how to do some keymap-making or key layout changing. Is there some sort of documentation on how to do this:

I'm interested in
function layer (s)
Mouse buttons
Hitting both shifts activates capslock

Y'know, things like that. Are there any resources you can share?

I might come up with some proposed keymaps for people.

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #715 on: Wed, 06 June 2012, 18:22:53 »
Quote from: dorkvader;608803
I'm interested in learning how to do some keymap-making or key layout changing. Is there some sort of documentation on how to do this:

I'm interested in
function layer (s)
Mouse buttons
Hitting both shifts activates capslock

Y'know, things like that. Are there any resources you can share?

I might come up with some proposed keymaps for people.

Dorkvader,

     The ultimate goal will be that when people get the keyboard, they will have access to our open source UI and firmware, which will allow them to use either the default QWerty / ic07 layout or any other layout of their choice (the software will automatically do any compiling and hardware flashing necessary). The UI will be Windows only, XP and above. If you're running linux, you'll have to manually edit the firmware, compile it, and flash the teensy 2.0 controller manually.

Mouse buttons won't be a part of the software as far as I know. I am not sure how the Teensy would handle this, seems to me it would almost have to register as two pieces of hardware to achieve. As far as we know, at the very least 2 layers will be available to the end users. A default and function layer. If you'd like to know what the default currently is, I point you to the source, or to sit tight until I can make a prototype UI available which will allow the designing of any custom layout of your choice. Let me know if you have any questions as I would be glad to help!

Cheers,

OJ
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline Salisen

  • Posts: 61
  • Location: United Kingdom
  • "Fire and Blood."
[Interest Check] Custom split ergo keyboard.
« Reply #716 on: Thu, 07 June 2012, 18:16:23 »
I'm definitely interested in getting one of these, ideally with a price lower than about $300.

I know I'm very new around here, but I potentially could provide a soldering service for 2-3 Europe based people (sending to the UK and back from outside of Europe would cost a fortune in custom's fees).  I'll be extremely busy around April to early June of 2013 due to the last exams of my degree, but I will otherwise have sufficient time.

I noticed someone mentioned in the Phantom thread about needing PCB designers.  On that note, electronics is a major hobby of mine: I have some experience with PCB design.  For this reason I'd be interested in helping design the PCB, but preferably working with someone who can check things I'm working on occasionally, I'm not confident about avoiding mistakes (I'm a physics undergrad, not an electronics engineer!).  I do have a bench supply, breadboard, etc though, so I can test layouts I design.
« Last Edit: Thu, 07 June 2012, 18:30:09 by Salisen »
| QPAD MK-80 |

Offline ic07

  • Posts: 190
[Interest Check] Custom split ergo keyboard.
« Reply #717 on: Thu, 07 June 2012, 23:14:20 »
Quote from: dorkvader;608803
I'm interested in learning how to do some keymap-making or key layout changing. Is there some sort of documentation on how to do this:


Not yet, unless you're comfortable with C and have time for a bit of reading.  I can post links to the relevant files again if you like.  But since OrangeJewce and effh are going to make a GUI, I'd recommend waiting for that.  I'm sure it'll be more fun to use, in any case :) .

- Function layers are being debugged.  Once done, I'm sure the GUI will make them easy to work with.
- Mouse buttons are in progress, but depend on my eventual comprehension of certain things about USB...  I'm trying!
- Hitting both shifts to activate capslock is a good idea.  I'll see what I can do after layers work right.  It /shouldn't/ be too hard.

Quote from: OrangeJewce;608836
Mouse buttons won't be a part of the software as far as I know. I am not sure how the Teensy would handle this, seems to me it would almost have to register as two pieces of hardware to achieve.


It will basically be pretending to be two devices, if I succeed in implementing it.  It's not an uncommon thing though - IIRC, several custom firmwares around geekhack have this feature (hasu's included) - I just need to figure out how to do it myself.

Quote from: OrangeJewce;608836
As far as we know, at the very least 2 layers will be available to the end users. A default and function layer.


Would more be useful?  I did the math just now, and I think there's room in flash for ~60 layers... lol.  And having extra allocated won't hurt.  How many do you think would be good?

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
[Interest Check] Custom split ergo keyboard.
« Reply #718 on: Thu, 07 June 2012, 23:33:17 »
An option you might want to look into is having layer lock key combos.  This way you could hit Fn-1 (or something similar) and it would switch to the 'qwerty' layer as the default until another layer lock is used.  This way a user could have several alternate layouts like dvorak and colemak at a simple key combo press.
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #719 on: Thu, 07 June 2012, 23:47:55 »
Quote from: ic07;609575
Not yet, unless you're comfortable with C and have time for a bit of reading.  I can post links to the relevant files again if you like.  But since OrangeJewce and effh are going to make a GUI, I'd recommend waiting for that.  I'm sure it'll be more fun to use, in any case :) .

- Function layers are being debugged.  Once done, I'm sure the GUI will make them easy to work with.
- Mouse buttons are in progress, but depend on my eventual comprehension of certain things about USB...  I'm trying!
- Hitting both shifts to activate capslock is a good idea.  I'll see what I can do after layers work right.  It /shouldn't/ be too hard.


I would strongly suggest just waiting it out unless someone else wants to get adventurous with compiling firmware. I haven't heard from effh in a while regarding the UI backend, so I might begin implementing part of it myself over the weekend. We'll just have to see how much time I have, or if he gets back to me. :thumb:

Quote from: ic07;609575

It will basically be pretending to be two devices, if I succeed in implementing it.  It's not an uncommon thing though - IIRC, several custom firmwares around geekhack have this feature (hasu's included) - I just need to figure out how to do it myself.


Alright so it would behave exactly as I thought. I didn't really think it was impossible, only that it couldn't be done with the controller registering itself as a single piece of hardware. There has been reports of by doing multiple registration, one loses correct functionality on a mac. This might need investigating if you manage to get mouse buttons implemented. I'm not sure how high up the ticket totem pole it is anyways.

Quote from: ic07;609575

Would more be useful?  I did the math just now, and I think there's room in flash for ~60 layers... lol.  And having extra allocated won't hurt.  How many do you think would be good?

I think people would like at least 3, up to (I could imagine) 6,

Qwerty+F'n
Dvorak+F'n/custom
Colemak+F'n/custom

I guess people might want more than that, but really it'd be a stretch for phase 1. The great thing is that I plan on having an export feature (might not be on release but I'm going to try), which will allow the community to share their layouts, and it will be modular because the UI will be able to flash the controller with just the .hex file.

Either way I'm still very excited about this project and look forward to delivering something at least usable by the community for creating, sharing, and distributing any layout they can possibly think of.

Cheers,

OJ
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #720 on: Thu, 07 June 2012, 23:55:00 »
also ic07 YGPM

Cheers,
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
[Interest Check] Custom split ergo keyboard.
« Reply #721 on: Fri, 08 June 2012, 00:40:27 »
I'd say we should have support for 4 layers, to accommodate practitioners of NEO.
I'd have:
Dvorak
QWERTY
Function
Special
as my layers (special would be a testing layout, if I want to update Dvorak some, or overflow from function) I will want to have some combination of QWERTY and dvorak, so if the computer is expecting dvorak or qwerty, I can use a layer to match.

Salisen, you're added to the list, but I haven't updated the OP yet.

Offline bpiphany

  • Posts: 1033
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
[Interest Check] Custom split ergo keyboard.
« Reply #722 on: Fri, 08 June 2012, 01:19:21 »
One thing about layers that I am afraid many might be missing is that the harware "layers" is not the full story. The keyboard still only sends a combination of keys. There are no actual functions associated wit what the keys do in the OS. That is all up to the OS to decide. If i want for example my '1'-key to be the '&'-key on another layer that will not be the same as defining say 'SHIFT'+'1' as '&', it will not be the shift layer. That layer would be a shifted layer where the '7'-key on a layer with 'SHIFT' activated. Since it is the OS that usually handles layers it is a bit backwards to do it in the firmware. There are of course workarounds.

On the Kinesis you can remap any key to do whatever any other key does. For example the switch the location of '1' and '&', and also program macro keys. The way I understand that they handle this is by defining every keypress as a keycode along with the modifier keys used for that particular key. That is every key is defined as a tuple of keycodes that are used simultaneously. If the '1'-key is set to be a '&'-key, the keyboard woll briefly send 'SHIFT'+'7' when the '1'-key is pressed. This works, but is a lot more tedious than I think everyone here is aware of =)

This is not the full story either... say I want a layer on my keyboard where the 'A'-key is an 'α'-key (alpha), Alpha is not even in the OS keymapping, no combination of keypresses will be able to produce it.

All this may be possible to solve installing other drivers or something, but that I know nothing about, and also that wouldn't be very pretty at all...

Offline sordna

  • Posts: 2248
[Interest Check] Custom split ergo keyboard.
« Reply #723 on: Fri, 08 June 2012, 01:32:55 »
Actually, the kinesis remaps entire keys. You can map 7 to 1 or 1 to 7 (dragging along the ! and & when shifted) but you cannot map 1 to & or 7 to ! or 1 to ! for that matter.
Macros can contain any letters, modifiers, and symbols, but key remapping is for entire keys.
Kinesis Contoured Advantage & Advantage2 LF with Cherry MX Red switches / Extra keys mod / O-ring dampening mod / Dvorak layout. ErgoDox with buzzer and LED mod.
Also: Kinesis Advantage Classic, Kinesis Advantage2, Data911 TG3, Fingerworks Touchstream LP, IBM SSK (Buckling spring), Goldtouch GTU-0077 keyboard

Offline bpiphany

  • Posts: 1033
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
[Interest Check] Custom split ergo keyboard.
« Reply #724 on: Fri, 08 June 2012, 01:46:53 »
Ok, I didn't really know. I only remember seeing the Kinesis at work sending modified keys in a keyboard testing program where the keys light up, and the shift key was coming on and off a lot =)

My own belief is that layers are best handled with custom character mappings on the OS side. This gives rise to the same portability issues as (potentially) having custom drivers.

My Linux workaround when I get around to implement it would be to have a complete keyboard mapping typed out into a terminal by some keypress combo. Could just be a heap of "xmodmap"-commandos or an actual xkb-file with all the bells and whistles. Keyboard mapping is a complete mess in Linux in my opinion.. Other OSs I don't really know about.

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #725 on: Fri, 08 June 2012, 08:48:25 »
Quote from: PrinsValium;609612
One thing about layers that I am afraid many might be missing is that the harware "layers" is not the full story. The keyboard still only sends a combination of keys. There are no actual functions associated wit what the keys do in the OS. That is all up to the OS to decide. If i want for example my '1'-key to be the '&'-key on another layer that will not be the same as defining say 'SHIFT'+'1' as '&', it will not be the shift layer. That layer would be a shifted layer where the '7'-key on a layer with 'SHIFT' activated. Since it is the OS that usually handles layers it is a bit backwards to do it in the firmware. There are of course workarounds.

We choose to alter the microcontroller because it's easier to do, and it works. Otherwise we'd need to craft OS specific drivers (not likely to happen).

Quote from: PrinsValium;609612
On the Kinesis you can remap any key to do whatever any other key does. For example the switch the location of '1' and '&', and also program macro keys. The way I understand that they handle this is by defining every keypress as a keycode along with the modifier keys used for that particular key. That is every key is defined as a tuple of keycodes that are used simultaneously. If the '1'-key is set to be a '&'-key, the keyboard woll briefly send 'SHIFT'+'7' when the '1'-key is pressed. This works, but is a lot more tedious than I think everyone here is aware of =)

This is not the full story either... say I want a layer on my keyboard where the 'A'-key is an 'α'-key (alpha), Alpha is not even in the OS keymapping, no combination of keypresses will be able to produce it.

All this may be possible to solve installing other drivers or something, but that I know nothing about, and also that wouldn't be very pretty at all...

My understanding is the Kinesis allows on the fly hardware mapping outside of the OS. Afaik, has no handle in how the keymap is stored, altered, or saved with regards to the onboard memory of the Kinesis' microcontroller. My guess is its memory is addressable and maybe they use some form of pointer system (pure speculation), and so you can shift around the addressing of the keys directly. Unfortunately for us to implement a feature similar to this would most likely consume much of the available memory on our controller and severely limit the number of layers, with limited additional benefit over a UI.

 Also it may or may not take more development time than we currently have, but I defer to ic07 on this issue, since he's doing all the low level work.
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline Salisen

  • Posts: 61
  • Location: United Kingdom
  • "Fire and Blood."
[Interest Check] Custom split ergo keyboard.
« Reply #726 on: Fri, 08 June 2012, 12:04:58 »
How are you looking to switch between layers?

From the keyboard's point of view, I mean.  My QPAD changes the backlighting brightness by holding fn and pressing one of two other keys.  Could also use some sort of 3-4 way DIP switch on the PCB.
| QPAD MK-80 |

Offline bpiphany

  • Posts: 1033
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
[Interest Check] Custom split ergo keyboard.
« Reply #727 on: Fri, 08 June 2012, 13:25:16 »
Quote from: OrangeJewce;609718
We choose to alter the microcontroller because it's easier to do, and it works. Otherwise we'd need to craft OS specific drivers (not likely to happen).

My point still stands. There are more and less unsolvable layout issues working with the keyboard side alone.


Quote from: OrangeJewce;609718
My understanding is the Kinesis allows on the fly hardware mapping outside of the OS. Afaik, has no handle in how the keymap is stored, altered, or saved with regards to the onboard memory of the Kinesis' microcontroller. My guess is its memory is addressable and maybe they use some form of pointer system (pure speculation), and so you can shift around the addressing of the keys directly. Unfortunately for us to implement a feature similar to this would most likely consume much of the available memory on our controller and severely limit the number of layers, with limited additional benefit over a UI.

 Also it may or may not take more development time than we currently have, but I defer to ic07 on this issue, since he's doing all the low level work.


There is 1kB of EEPROM memory where the firmware can save settings from time to time. That is a lot of layouts.. Keycodes are only 1 byte, pointer probably the same. As Sordna said the Kinesis only supports swapping keys, not really remapping individual "characters". A key swapping function should be fairly straight forward to implement...

No need to have the firmware "finished" before the physical product is finalized. The prototype is a perfectly well functioning keyboard (ok there may possibly be some bugs). The Teensy is infinitely re-programmable, and this is easily done as well. You will have forever to improve upon the firmware.

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #728 on: Fri, 08 June 2012, 14:07:33 »
Quote from: PrinsValium;609822
My point still stands. There are more and less unsolvable layout issues working with the keyboard side alone.

I guess I don't understand then exactly what your point is, so I apologize. The design decision was made to work from the keyboard end to ensure compatibility with any OS, because that would mean doing a single implementation as opposed to many. There are always going to be pros and cons to any design decision.

There really isn't such a thing as "Finished" in programming, as one can always improve it. However, the firmware should be stable and have some basic features that are cornerstones of why we are undergoing this project. Remapping is one of those features. However, we shouldn't get into an argument about coding methodology here, I don't feel this is the right place.

If you would like to draft up drivers for Windows or any of the other OSes we'd be more than happy to see what it is you come up with. The more the merrier :thumb:.

Cheers,
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline effh

  • Posts: 6
[Interest Check] Custom split ergo keyboard.
« Reply #729 on: Fri, 08 June 2012, 15:50:03 »
For those wishing to play with the windows side of keyboard-layouts, I found this utility belonging to microsoft.

http://msdn.microsoft.com/en-us/goglobal/bb964665.aspx

I've not done more than download it yet, but I'm looking to cure my caps-lock problem.....
:  )

Update: Okay, so that is the next best thing to useless - for some reason, some specific keys can not be changed... like caps-lock. I note that this utility does allow you to specify alternate shift mappings, so combined with changing the actual keyboard firmware may form part of a complete solution.

Offline mSSM

  • Posts: 50
[Interest Check] Custom split ergo keyboard.
« Reply #730 on: Fri, 08 June 2012, 18:47:13 »
What do you guys think - can this be a good replacement for a Kinesis?

And is there an ETA for the "final" prototype (including the case)?


I am deliberating getting either the Ergo Dox or the Kinesis; I can't afford both. :(

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
[Interest Check] Custom split ergo keyboard.
« Reply #731 on: Sat, 09 June 2012, 01:04:28 »
Quote from: mSSM;610027
What do you guys think - can this be a good replacement for a Kinesis?

And is there an ETA for the "final" prototype (including the case)?


I am deliberating getting either the Ergo Dox or the Kinesis; I can't afford both. :(
I've not tried a TE, but I see this as a better version of that.

Also keep in mind that whatever you get, you can probably resell it for most of the value in the classifieds once you're done.

Offline hoggy

  • * Ergonomics Moderator
  • Posts: 1502
  • Location: Isle of Man
[Interest Check] Custom split ergo keyboard.
« Reply #732 on: Sat, 09 June 2012, 02:18:50 »
The resale value of the ergodox is likely to be close to the final price.

If you buy the Kinesis first,  you will probably miss out on the ergodox. If you buy the ergodox,  you'll have the option of the Kinesis later.
GH Ergonomic Guide (in progress)
http://geekhack.org/index.php?topic=54680.0

Offline mSSM

  • Posts: 50
[Interest Check] Custom split ergo keyboard.
« Reply #733 on: Sat, 09 June 2012, 08:29:10 »
Quote from: hoggy;610193
The resale value of the ergodox is likely to be close to the final price.

If you buy the Kinesis first,  you will probably miss out on the ergodox. If you buy the ergodox,  you'll have the option of the Kinesis later.

Good point; my impression was that the resale price of the Kinesis is reaaaally bad. Neither here nor on deskthority are people particulary interested in those. And eBay is even worse. Last Kinesis went for 25% of its original price. :(

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #734 on: Sat, 09 June 2012, 10:36:07 »
Quote from: mSSM;610275
Good point; my impression was that the resale price of the Kinesis is reaaaally bad. Neither here nor on deskthority are people particulary interested in those. And eBay is even worse. Last Kinesis went for 25% of its original price. :(

The ErgoDox will be a really unique, and most likely will be a rare piece of hardware. For that reason alone you can expect it to retain value well.

Cheers,
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline bpiphany

  • Posts: 1033
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
[Interest Check] Custom split ergo keyboard.
« Reply #735 on: Sat, 09 June 2012, 11:06:50 »
Quote from: OrangeJewce;609869
I guess I don't understand then exactly what your point is, so I apologize. The design decision was made to work from the keyboard end to ensure compatibility with any OS, because that would mean doing a single implementation as opposed to many. There are always going to be pros and cons to any design decision.


I've explained as well as I think I am able to. I'm only trying to warn you to not try to solve an unsolvable problem. The limitations that come with working from the keyboard side alone may or may not apply to your needs. I'm just saying that everything cannot be done that way.

Quote from: OrangeJewce;609869

If you would like to draft up drivers for Windows or any of the other OSes we'd be more than happy to see what it is you come up with. The more the merrier :thumb:.
Cheers,


If I had any idea how to do it, I probably wouldn't be that crazy.




My point is that keymappings on the OS side solves all but the portability issues. It would have been easier if keyboards were designed to send unicode characters or something similar, and the OS would handle only the conversion if another map than the physical one on the keyboard was required. There are of course good reasons to why it is the way it is as well.

I know how to do keyboard mappings in Ubuntu (sort of). It is insanely messy for such a simple thing but it works and it solves most problems much more nicely.

Edit: Ok, most problems might be an exaggeration, but there are a lot more options altering the OS key mapping. And I also wanted to add that there already is layer support in the firmware if I understand correctly. It might just not be completely bug free.
« Last Edit: Sat, 09 June 2012, 13:52:05 by PrinsValium »

Offline Icarium

  • Posts: 251
  • I AM A MONKEY!
[Interest Check] Custom split ergo keyboard.
« Reply #736 on: Sat, 09 June 2012, 14:15:00 »
I thought on the windows side people were pretty happy with what Autohotkey can do?
I had a sig once but it's gone. It used to display an icon of a Kinesis. Just imagine that.

Offline REVENGE

  • Posts: 568
[Interest Check] Custom split ergo keyboard.
« Reply #737 on: Sat, 09 June 2012, 15:26:23 »
Quote from: Icarium;610387
I thought on the windows side people were pretty happy with what Autohotkey can do?
It's not ideal: not easily portable, does not work with certain programs.
◕ ‿ ◕

Offline Salisen

  • Posts: 61
  • Location: United Kingdom
  • "Fire and Blood."
[Interest Check] Custom split ergo keyboard.
« Reply #738 on: Sat, 09 June 2012, 17:48:31 »
Quote from: REVENGE;610414
It's not ideal: not easily portable, does not work with certain programs.

I think it can be flagged up by anti-cheating software in games as well.  Not really worth the risk.
| QPAD MK-80 |

Offline hoggy

  • * Ergonomics Moderator
  • Posts: 1502
  • Location: Isle of Man
[Interest Check] Custom split ergo keyboard.
« Reply #739 on: Sun, 10 June 2012, 02:29:54 »
Quote from: mSSM;610275
Good point; my impression was that the resale price of the Kinesis is reaaaally bad. Neither here nor on deskthority are people particulary interested in those. And eBay is even worse. Last Kinesis went for 25% of its original price. :(

There you go then. Get the Kinesis board from here or ebay and then get the ergodox in this group buy.

The Kinesis is a great board,  if you think you need one,  get one!
GH Ergonomic Guide (in progress)
http://geekhack.org/index.php?topic=54680.0

Offline ic07

  • Posts: 190
[Interest Check] Custom split ergo keyboard.
« Reply #740 on: Sun, 10 June 2012, 21:40:08 »
Quote from: alaricljs;609580
An option you might want to look into is having layer lock key combos.  This way you could hit Fn-1 (or something similar) and it would switch to the 'qwerty' layer as the default until another layer lock is used.  This way a user could have several alternate layouts like dvorak and colemak at a simple key combo press.


Layer lock key combos are a good idea, and would be easy to put on a key in a function layer.  I'll plan to add that capability in a bit.  Thanks!


Quote from: OrangeJewce;609584
I think people would like at least 3, up to (I could imagine) 6

Quote from: dorkvader;609602
I'd say we should have support for 4 layers, to accommodate practitioners of NEO.


Mmkay.  Thanks :) .  I think I'll allocate 10 then, by default, just to have a nice round number.  Having extra shall not hurt.


Quote from: OrangeJewce;609718
My understanding is the Kinesis allows on the fly hardware mapping outside of the OS.
...
Also it may or may not take more development time than we currently have, but I defer to ic07 on this issue, since he's doing all the low level work.

Quote from: PrinsValium;609822
There is 1kB of EEPROM memory where the firmware can save settings from time to time. That is a lot of layouts.. Keycodes are only 1 byte, pointer probably the same. As Sordna said the Kinesis only supports swapping keys, not really remapping individual "characters". A key swapping function should be fairly straight forward to implement...


It would be possible to implement Kinesis like remapping, but it involves tradeoffs that, the more I think about them, the less I want to make them.  A complete layer (keycode + two function pointers for a 12x7 matrix, function pointers being 16 bit) is 420 bytes, which means the EEPROM could actually only hold two.  We could limit special functions from maps with that capability, and store only the keycodes in the EEPROM, or I could devise a method for only storing changed layout info there; or we could limit the number of layers to two.  But I don't really like the idea of doing any of that for such an (IMO) limited gain in functionality.  I'm open to reconsider though, if I find that there's really enough interest.


Quote from: Salisen;609782
How are you looking to switch between layers?

From the keyboard's point of view, I mean.  My QPAD changes the backlighting brightness by holding fn and pressing one of two other keys.  Could also use some sort of 3-4 way DIP switch on the PCB.


We're switching layers using keypresses (fn/layer keys).  Layer lock key combos are planned (thanks to alaricljs for the suggestion).  If anyone wants to change the keyboard's default/startup layer though, they'll have to reflash the controller (but that should be easy enough, especially on Windows once OrangeJewce and effh are done with their UI).


Quote from: PrinsValium;610342
My point is that keymappings on the OS side solves all but the portability issues.


It doesn't though.  Remapping any of the 'lock' keys, for instance, is hard to do OS side.  But I understand what you're saying about limitations.  Personally, I'm going to use both methods (OS remapping for Greek characters and OS functions, firmware for everything else).

Offline bpiphany

  • Posts: 1033
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
[Interest Check] Custom split ergo keyboard.
« Reply #741 on: Mon, 11 June 2012, 02:44:12 »
Quote from: ic07;610998
It would be possible to implement Kinesis like remapping, but it involves tradeoffs that, the more I think about them, the less I want to make them.  A complete layer (keycode + two function pointers for a 12x7 matrix, function pointers being 16 bit) is 420 bytes, which means the EEPROM could actually only hold two.  We could limit special functions from maps with that capability, and store only the keycodes in the EEPROM, or I could devise a method for only storing changed layout info there; or we could limit the number of layers to two.  But I don't really like the idea of doing any of that for such an (IMO) limited gain in functionality.  I'm open to reconsider though, if I find that there's really enough interest.

Store a backup of the "standard" 12x7 layout array, after that there should be room for perhaps 11 more copies of this that can be modified any way required. The base array could be stored in flash memory as well. That would give room for another one as well as protect it from corruption =) I don't know if on the fly remappings like on the Kinesis is very useful when you can program the keyboard anyway you like anyhow. Storing macros in the EEPROM sounds more interesting to me. I envision those as linked lists of (key, modifiers, next pointer)-triplets. Each list item would take 4 bytes if pointers are 2 bytes.

Quote from: ic07;610998
It doesn't though.  Remapping any of the 'lock' keys, for instance, is hard to do OS side.  But I understand what you're saying about limitations.  Personally, I'm going to use both methods (OS remapping for Greek characters and OS functions, firmware for everything else).

Of course you are correct. Things the OS doesn't need to know about is best kept in the dark =) I should have said that "character mapping" problems are best solved on the OS side. Once again macros might be the solution I'm actually looking for. Do I want to type 'λ' or really just "\lambda"? =D



There is also a micro SD-card adapter for the Teensys. Imagine GBs of data... I had plans to use one as a keylogger on my own keyboard. I haven't been experimenting any with it, but there are adapters in my home built boards.

Offline ic07

  • Posts: 190
[Interest Check] Custom split ergo keyboard.
« Reply #742 on: Mon, 11 June 2012, 06:12:55 »
Quote from: PrinsValium;611101
Storing macros in the EEPROM sounds more interesting to me. I envision those as linked lists of (key, modifiers, next pointer)-triplets. Each list item would take 4 bytes if pointers are 2 bytes.


Hmm, I hadn't been thinking about macros; and I would think those were easier to do in the OS (or.. I use gvim, so that's where mine are).  Still interesting though, maybe I'll think about them again sometime when I'm not so tired :) .  Would you prefer them in firmware?  If so, why?


[/HR]

DOX:
Updated firmware in 'dev'!  And new .hex posted.  Hopefully those layer switching problems are gone now... please let me know if you test it.  It seemed to be working properly in my cursory little breadboard test.

OJ, effh:
I touched lib/key-functions* a bit, but I didn't change any function names (or get around to adding any yet).  Most of the layer logic that changed was in main(), and I can't recall doing anything that would effect you guys.

And I think that's it.  I'm tired, coz it's really late o_o , but I wanted to get the modified layer code out as soon as I could, in case DOX was waiting for it.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
[Interest Check] Custom split ergo keyboard.
« Reply #743 on: Mon, 11 June 2012, 09:19:08 »
Quote from: PrinsValium;611101
There is also a micro SD-card adapter for the Teensys. Imagine GBs of data... I had plans to use one as a keylogger on my own keyboard. I haven't been experimenting any with it, but there are adapters in my home built boards.
Hmm, interesting! This would also guarantee I'd never be able to take it into work and use it, though. In a similar vein, are there any good programs (linux or windows) that track how many keystrokes you've done? Sort of a mouse odometer for the keyboard. Peel free to PM me so as not to get too far off topic if you must.

Also< I'd lay that macro-functionality would probably be pretty useful. I can imagine using it for a number of things.

Offline OrangeJewce

  • ssk.ℜ
  • Posts: 495
  • Location: Minnesota
  • King of the Jewce
[Interest Check] Custom split ergo keyboard.
« Reply #744 on: Mon, 11 June 2012, 09:59:53 »
Quote from: PrinsValium;611101
...Of course you are correct. Things the OS doesn't need to know about is best kept in the dark =) I should have said that "character mapping" problems are best solved on the OS side. Once again macros might be the solution I'm actually looking for. Do I want to type 'λ' or really just "\lambda"? =D...

Quote from: ic07;611126
Hmm, I hadn't been thinking about macros; and I would think those were easier to do in the OS (or.. I use gvim, so that's where mine are).  Still interesting though, maybe I'll think about them again sometime when I'm not so tired :) .  Would you prefer them in firmware?  If so, why?...

Quote from: dorkvader;611178
Hmm, interesting! This would also guarantee I'd never be able to take it into work and use it, though. In a similar vein, are there any good programs (linux or windows) that track how many keystrokes you've done? Sort of a mouse odometer for the keyboard. Peel free to PM me so as not to get too far off topic if you must.

Also< I'd lay that macro-functionality would probably be pretty useful. I can imagine using it for a number of things.

I have to agree with the above, Dork, the OS is much better suited for macro handling than the firmware. I still disagree with Prins' assertion that the OS is better for handling character mappings than the KB when you're working with a non-standard layout, but it's a dead horse at this point. But hey, if macros make it into the firmware at some point (maybe after initial release?) that would be fantastic.

No updates yet on the GUI, I plan on putting in some hours this week to see if I can get a "Shell" of it working by the weekend.

Cheers,
IBM Model M 1390120, Otaku Unicomp+RGB, CM QFR Green, Ducky YOTD Red, SSK MKII,
ErgoDox Blue, ErgoDox White

Offline bpiphany

  • Posts: 1033
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
[Interest Check] Custom split ergo keyboard.
« Reply #745 on: Mon, 11 June 2012, 14:29:30 »
A friend who has both a Kinesis and one of my Teensy keyboards wrote his own basic macro functionality for the latter. I know he uses it for some things, but not really exactly what. I know I myself often do repetetive things on the keyboard. I should probably do them in smarter ways to start with. But some basic macro functionality is a good start to not learn to do things right =)

Putting the macro functionality on the OS side once again screws up portability.. My vim-fu is very faint. I guess emacs does macros too, I just haven't learned. But they could be useful in other contexts as well.

The same friend as above also use a keylogger (in the OS though) to collect statistics of keypresses. He says it never seizes to be disturbing to see his passwords in clear text =D There should be plenty of keylogger available from fishy corners of the net. Search for key logging and take the plunge...

Quote from: OrangeJewce;611203
I still disagree with Prins' assertion that the OS is better for handling character mappings than the KB when you're working with a non-standard layout, but it's a dead horse at this point.


I'm not going to argue too much about this. But there are limitations you just can't get around. Getting characters that are not in the map the OS is set to for one is next to impossible (macro alt-codes might solve that though...). Moving characters between layers of different "shift-depth" will get pretty messy and involve sending shift/alt-combos even when they could be unwanted. But hey, I don't really care =)

Edit: Function keys and an embedded numpad would be things best handled as layers in firmware. But that much I think we all agree about.
« Last Edit: Mon, 11 June 2012, 16:17:10 by PrinsValium »

Offline ic07

  • Posts: 190
[Interest Check] Custom split ergo keyboard.
« Reply #746 on: Mon, 11 June 2012, 17:33:01 »
About macros, now that I've slept, I can see there being times where i'd like to have them in firmware.  How to implement, and whether or not I feel they're justified (personally), I'm not sure yet.  I've opened an issue on github, if anyone's concerned... :) or discussion can continue here of course.

Offline Netdewt

  • Posts: 187
  • OLKB
[Interest Check] Custom split ergo keyboard.
« Reply #747 on: Mon, 11 June 2012, 20:53:24 »
I wish I had something intelligent to contribute to this thread.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
[Interest Check] Custom split ergo keyboard.
« Reply #748 on: Mon, 11 June 2012, 23:00:16 »
Quote from: Netdewt;611679
I wish I had something intelligent to contribute to this thread.
Registering your interest counts as an intelligent contribution.

Very intelligent, in this case.

Offline Zifle

  • Posts: 166
  • Location: Denmark
  • Nyaaa
[Interest Check] Custom split ergo keyboard.
« Reply #749 on: Tue, 12 June 2012, 01:48:09 »
Quote from: dorkvader;611743
Registering your interest counts as an intelligent contribution.

Very intelligent, in this case.

In that case, I would like to register my interest as well!
Speaking of, which time frame are we looking at at this point? A couple of months, a year ... ?

I wouldn't be able to afford in the next two or three months, but later in the year, I'd most likely have the finances to cover it.

I've been thinking, not sure whether this has been discussed previously, as I haven't followed the thread the whole way through, will we be able to use either side of the board independently of the other? I could see myself / others wanting to use it as a gaming pad, without having to necessarily have both sides on the desk.
I like cats.