I think I have a need-for-sudo script snippet in my xkb install script; I'll see if I can implement that for this one as well! I read Hasu's warning that you (may) need sudo but then I didn't after all. So I guess it's a matter of OS flavour.

Running my script with sudo doesn't give the desired results, I take it? (Don't do that when running it with the installing switches!) Oh, and did you notice this bit in the sh script comments?

NOTE: To avoid sudo make for flashing the USB-2-USB, put this into /etc/udev/rules.d/50-atmel-dfu.rules:
# Atmel ATMega32U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", MODE:="0666"

We debated the position of the 6 key in our original Wide mod thread. If you like matrix keyboards you may prefer it to the right, but otherwise I find it makes more sense to the left. The stretch to 6 on a normal-staggered keyboard is shorter for the left hand, and it's to the left on several split-keyboard models. Furthermore, I think that putting it on the right hand leads to the = key switching hands which isn't ideal?

I won't provide an additional slew of keyboard "models" to cater to your 6-on-the-right needs, I'm afraid, as that would be just too confusing. You should find it easy enough to edit the dreymar.h file to suit your needs; I've gone to great lengths to make the key names therein understandable!

The naming of keys is a difficult matter, it isn't just one of your everyday games. ;-) The issue is that I define certain keys (Tab, Caps, ScrlLck, Pause...) as Fn## keys instead of their old selves, then set their new function in the action key definitions. So this is sort of an endian-ness debate: You want to name them by function, I want to assign their function to the key. For most of the Fn## keys you'll find that I provide a setting to be something, alternatively maybe something else, or their ordinary self. It just wouldn't do to set the "Ext1" key to be something else! I would contend that if you want to change the Caps to non-Extend and LAlt to Extend for instance, then with my way you can change one single setting in the action key defs but with your way you'd have to search-replace two keys in all the layout files.

So for now I'll keep my way. You're free to call your Fn keys whatever you want of course.

I really should set DREYMARHACK to 0 by default, of course. But then I end up using it for my own purposes and leave the lights on. ;-)

Isn't it clear enough that the ergo mods reside in the .h file? I tried to make it understandable but I may have taken some things for granted.
[Edit: I went over the posts and made things hopefully more instructive. Have a look at page 1.]

If you move the FCap key and then set EXTENDMODE to 0, that key will become CapsLock or something else (dependent on CAPSBEHAVIOR). Is that what you want?

[edit: I fixed my last commit to use DREYMARHACK 0, and nuked a lot of old and pointless history. I know, I "changed history" and one really shouldn't do that! Please re-clone and add your file again. I'll also use your idea of .gitignore-ing the hexfile folder, thanks!]

For my testing: Can you run dfu-programmer on the command line without any arguments, or does it need sudo for that too? If you can run it directly without sudo, then please find a condition that requires sudo. I'm aiming for something like this in my script:

#MyChip='atmega32u4'
    ## Check whether dfu-programmer needs root access to run (actually, try it with sudo if it doesn't run successfully without)
    [ "`dfu-programmer <anything-needed-here?> 2>/dev/null`" ] && DoSudo='' || DoSudo='sudo'	# check whether it runs as user
    ## The dfu-programmer command has slightly different syntax depending on version
    [[ `dfu-programmer --version 2>&1 | awk '{print $2}'` > '0.7' ]] \
        && UseForce='--force' || UseForce=''
    ${DoSudo} dfu-programmer $MyChip erase $UseForce    || MyError "$MyChip init/erase failed"

I don't think dfu-programmer works at all with Ubuntu-on-Windows10, yet. A web search confirmed that it can't access USB devices properly ("can't init libusb").

You could still use my script with sudo if you only flash with it. So you'd run it once with normal privileges to build and then again with sudo and -bf to flash without building. Obviously don't run cleanup in between, or you'll have to point dfu-programmer towards your backup .hex file. If you re-read my Flashing post on the first page, you'll find this info there. ;-)

[edit: I think <anything-needed-here?> can be 'get bootloader-version', which makes dfu-programmer attempt to contact the USB device]

SteveP:

Actually, the best way for you to move LAlt/LWin/Caps and other keys to suit your preferences and also get your preferred ergo mod might be to create a new ergo model in the .h file (or cannibalize the AWIDEISO model currently in use – but leave mine in there with a different name). That way you won't have to modify any layouts and I think it's a bit more "proper" as this is the way I think about moving keys and not just the glyphs on them. (So for instance the Wide mod is a .h mod, while Curl-DH is a .c mod if you catch my drift.)

This is a dumb, Dumb, DUMB question, but... wireless keyboards? Does this method work at all? I can't imagine it would, but... hope springs eternal, y'know?

How about Bluetooth? In the form of Computer>USB2USB>Bluetooth Dongle>Bluetooth Keyboard.

Could this be made into a Bluetooth/USB-2-Bluetooth/USB project? Theoretically I mean. Requesting that as a feature would be entirely unreasonable, but technically... technically you could use your phone as a go between. BTKeyboard>Phone>Computer is doable with available apps, but that would put a lot of drain on your phone. Having a stand alone box do it, or one that you simply plug into a machine, that would be pretty slick. Kinda a DIY autopairing dongle.

PS. I hate the word "dongle". Whoever came up with it should be drug out into the street and shot. Not fatally you understand. Just, y'know, enough that they can't breed.

I don't see any reason why it shouldn't work, short of a chance there'll be too low voltage for the Bluetooth adapter or something.

In principle, a Wi-Fi or Bluetooth adapter is always mounted as a HID keyboard I think? Which means that you can put the QUICKIE in between the adapter and the computer and Bob's your uncle.

If your keyboard doesn't have an adapter like that but just communicates via your Wi-Fi, it won't work because you don't have any USB HID signals to translate. In this case, one can only hope that you can use an OS solution instead.

Hey Dreymar! (TL;DR at the bottom)

Some time ago I was dealing with making my own PKL keyboard with extend layer. I finnished it but now I need a USB-to-USB or PS/2-to-USB device in order to use the keyboard at my new work. You know, PKL, in fact, is a (non-malicious) keylogger. So, when I used it, bad things happened.

I'm planning to buy a mechanical keyboard, maybe from WASDkeyboards. I've seen that their keyboards are 6KRO over USB but, if you use a USB-to-PS/2 converter that they send with the keyboard, it is NKRO. For me it doesn't matter if it is 6KRO or NKRO.

I've been reading Hasu's threads at GeekHack and and I don't know if I should buy the USB-to-USB one or the PS/2-to-USB one.

The thing that frightens me is the capability to send mouse buttons and movements with the extend layer:
·In the USB-to-USB thread it says that it has no mouse or other pointing devices support. (I understand that it can't remap a keyboard + mouse device)
·In the PS/2-to-USB thread it says that it has the feature that it can emulate mouse moves and button clicks using keyboard. Also, another feature is that it's possible to send key events like: system control(Power down, sleep,...), Volume down/up and Mute, Media control, Application launch, Browser control. (This makes me think that the USB-to-USB can't do that)

TL;DR: So, with the USB-to-USB converter is possible to have a extend layer with mouse button clicks, mouse movements and media buttons as Volume up? Also, USB-to-USB converter has a limited flash space, does your keyboard fit completely in the USB-to-USB memory, including the extend layer? (I know that deadkeys are only available using PKL, that's not a problem)

Thank you very much and sorry for the long text.

I think I didn't understand the PS2 part of your message. WASD keyboards come with USB and 6KRO. In addition, they send a USB-to-PS/2 adapter to enable NKRO (I don't know how, but that's what they say). So, I suppose, the USB-to-USB converter should work fine with the USB keyboard as-is, without adapters, shouldn't it?

I should think so, since the USB keyboard seems to send normal USB protocol (6KRO). I'm really not sure how their adapter could enable NKRO (which PS/2 does support) based on the USB input, without adding more info! One way, as I said, is to use two USB plugs bringing you to 12KRO which is enough unless you're an alien. Another way is to hack the USB protocol's transfer speeds but then I think you'll need something aware on the receiver side which could be how that adapted does it. I don't know.

Keep in mind that USB sends key events and not input events! So it's not Shift aware and cannot inherently send glyphs whether cased or not. It can send a shift-key-down followed by another key, of course, which would amount to upper case on most systems, but it cannot send upper case as such – bar some clunky, OS dependent hacks like sending Alt+NumPad(####) on Windows.

So what I meant is typically Colemak and QWERTY yes, allowing you to switch the keyboard to guest-friendly or password-friendly mode with a hotkey (I use ScrollLock). For Colemak learners it could be a Tarmak instead. And I think memory should be sufficient for at least a third layer if desirable, but I haven't written the code for that. I think it's better to just re-flash the device as your needs change, to avoid clutter. I haven't implemented any LED feedback to show what you've chosen so there's that too.

Ummm, no. The OS layout maps key codes to input events which the TMK (or more precisely, the USB HID or pretty much any keyboard hardware protocol) doesn't. The keyboard/TMK only sends key codes!

So if you've got a low-level remapping in your OS (like registry remapping on Windows) your key code will get translated again by the OS. And more to the point for most, the OS layout will determine what happens when Shift/Ctrl/AltGr states are active. It matters whether you have the plain boring US layout or, say, Canadian International active.

But with the TMK device or any other programmable keyboard, you may redirect any press of the Y key to a [ key press for instance. Then the OS layout will determine what to do with a [ key press; the Norwegian layout would send the letter å (or Å if the Shift state is active in the OS input system).

The keyboard may do some tricks like capture certain key combos (e.g., if you press AltGr+[ it'll send something special), but in the end all it can send is key codes.

Fine, that f***s up all my keyboard layout because I made it from scratch using PKL, which sends characters.

For instance, the US QWERTY "/?", which is next to the right left, I made it like "?/".
Do you know if its possible to make those kind of remappings with TMK? Something like, if I press "/?" it sends Shift + "/?" and if I press Shift + "/?" it sends "/?".

Here are my normal and shift layers, so you can take a look:

Do you say that it's doable as long as only a few keys need to be swapped due to the short memory or due to some other thing? Because I could get a PS/2-to-USB converter, which don't have that memory problem.

I've read that some people have tried to do a unicode keyboard but, for that, it's needed to implement a custom driver since any OS would support it. I also read something about that it's not recommendable to do it because it would bypass some Windows layer used for something.

Mmm... That sounds very interesting, I'll take a look as soon as I can. That lig prefix what does exactly?