Unicomp terminal layout options

[Pixel_Outlaw]

I see tha t Unicomp offers quite a selection of layouts for their terminal keyboards. I'd like to get one of these for my desktop computer with the extra keys because they look damn cool. It looks like they will play nice with a normal computer (or atleast that is the impression I get from Unicomp's website).

Now if somebody could explain the different layout options it would help me decide.

They offer
5250
3270
PC/5250 PS2
PC5250USB

I'm not sure what to pick. I'm not sure if only some will work with Linux/Windows. I like the look of the standard model M but I do like those additional function keys. Then again it might be neat to have the + style directional keys and that horrid | enter key. Maybe somebody here can help me choose one.

Here is what I'm looking at.
http://pckeyboards.stores.yahoo.net/122keyterkey.html

[theferenc]

We actually had a discussion about this not too long ago here. The conclusion being that you want something like this:

Type: Emulator
 Layout: 3270 Format (or whatever)
 Cable: USB
 Keyswitch: Buckling spring (whatever color)

The 3270 layout is what the 1397000 uses. It's pretty close to ISO, but is easily converted to whatever you want with a bolt mod.


Edit: I believe the 5250 uses the same physical layout, but different keymap. From what pictures I can find, that's the conclusion I was able to come to. 3270 is pretty useful, and easily remapped to whatever, even in software, be it AHK, registry remaps via KeyTweak, or xmodmap in linux.

[7bit]

I see tha t Unicomp offers quite a selection of layouts for their terminal keyboards. ...

They offer
5250
3270
PC/5250 PS2
PC5250USB
...

 
I will get the 3270 Emulator.

If you live in EU Europe, you can participate in a mini group buy I currently run at deskthority.org and save some money.

@theferenc:

Type: Emulator
Layout: 3270 Format (or whatever)
Cable: USB
Keyswitch: Buckling spring (whatever color)

Do you know if the USB version would really work? It had been discussed in the other thread that PS/2 top USB does not work and I tried it myself with my 3270 clone from Cherry (G80-2550) and got the same result.

[theferenc]

If it's native USB, it should work. It's the converter that drops the extra scan codes, not the USB HID spec. If you program your own converter to accept and pass those keys, they do work via USB. I modified Hasu's converter to do exactly that (and change the layout at the same time).

One of these days, I'll have to order one of those from Unicomp. But for right now, I have 3 1397000 keyboards that work perfectly well. I only need 2 though, so maybe I should sell 2 of these, and buy a USB unicomp as a replacement, just to check it. At least I don't have to pay much for shipping...and I could probably get it natively the layout that I want. Hmmm...

[7bit]

If it's native USB, it should work. It's the converter that drops the extra scan codes, not the USB HID spec. If you program your own converter to accept and pass those keys, they do work via USB. I modified Hasu's converter to do exactly that (and change the layout at the same time).

One of these days, I'll have to order one of those from Unicomp. But for right now, I have 3 1397000 keyboards that work perfectly well. I only need 2 though, so maybe I should sell 2 of these, and buy a USB unicomp as a replacement, just to check it. At least I don't have to pay much for shipping...and I could probably get it natively the layout that I want. Hmmm...

 
If I had 3 genuine IBM 1397000 I would not bother to but a new one from Unicomp.

Maybe I will get one in USB version, just to give it a try.

[Pixel_Outlaw]

So essentially you are also telling me that even though you can get something in USB from them, it might not work?

So it might be safer to go with a ps2 model and then use my active keyboard (adesso) cable to convert the signal to USB for future computers?

Can anyone provide me with further information between the physical button locations? I'm pretty new to the different layout styles. I've pretty much had the standard IBM all my life.

[7bit]

So essentially you are also telling me that even though you can get something in USB from them, it might not work?

So it might be safer to go with a ps2 model and then use my active keyboard (adesso) cable to convert the signal to USB for future computers?

Can anyone provide me with further information between the physical button locations? I'm pretty new to the different layout styles. I've pretty much had the standard IBM all my life.

 
No!

The safest way is to get a PS/2 model and connect it to a PS/2 port. The converter will not work (out of the box).

If nobody ever tried a USB, I will get one in my mini group buy and test it.

Everything can be remapped. If youv'e got something running with X11, theferenc can help you with xmodmap, or if you don't like it, I can help you changing doing the change directly in the xkb config files.

[Pixel_Outlaw]

Oh Ok, thanks for the correction.
I guess I want the best of both worlds since I have some older computers that use PS/2 and also I heard that only usb is available on some newer motherboards.
I guess I just want to sit behind the keys of a terminal style keyboard to confuse my enemies, amaze my friends, and get all the girls!
I don't toss around $120 dollars every day so I want to invest in something that is going to suit my needs in multiple situations.

[theferenc]

If I had 3 genuine IBM 1397000 I would not bother to but a new one from Unicomp.

Maybe I will get one in USB version, just to give it a try.

Well, my thought is more to put this particular discussion to bed. I just can't afford to buy one just out of hand at the moment.

But I'm definitely under the impression that the problem is the converter, not the USB aspect.

As for xmodmap, I certainly can help. The only advantage it has over the xkb config files is that it works on systems for which you do not have root. xkb works with [xgk]dm though, which is a nice feature if you do significant main block changes.

Does anyone know if the purple dongles work on a USB model without tossing out the extra scan codes? If that works, and the USB model works as I think it does, that might actually be your best bet, long term.

One of us 122 key users needs to just bite the bullet though and buy one to test it. Either 7bit in your group buy, or me, or someone. Unfortunately, only the Unicomp firmware engineers know for sure, and I haven't been able to get a straight answer out of them about this in the past. I should just ask to stop buy, bring a laptop, and connect one to it in their offices. Or maybe not...

Edit: Oh, and just to be clear, the Emulator model is the one that sends unique codes for the extra keys, rather than modifier combinations.

[theferenc]

Well I guess that shoots that idea in the foot. Thanks ripster.

[7bit]

Well, my thought is more to put this particular discussion to bed. I just can't afford to buy one just out of hand at the moment.

But I'm definitely under the impression that the problem is the converter, not the USB aspect.

As for xmodmap, I certainly can help. The only advantage it has over the xkb config files is that it works on systems for which you do not have root. xkb works with [xgk]dm though, which is a nice feature if you do significant main block changes.

I tried with xmodmap but I had the problem that never all modifier keys worked together.
(ie Shift, Alt, Control, Meta, Super, Hyper, Caps Lock and Num Lock)

...
One of us 122 key users needs to just bite the bullet though and buy one to test it. Either 7bit in your group buy, or me, or someone. Unfortunately, only the Unicomp firmware engineers know for sure, and I haven't been able to get a straight answer out of them about this in the past. I should just ask to stop buy, bring a laptop, and connect one to it in their offices. Or maybe not...

Brilliant idea!

Do it!!!

[theferenc]

They are only a couple hours from me, and I drive pretty close to their offices a few times a year.

One of the quirks I've noticed sometimes with xmodmap is that order matters in regards to the modifiers, in terms of your config file. It's quirky, but it usually works in the end. I have noticed that if I use xkb to remap my caps lock and control keys, order matters in regards to remapped control and shift, for whatever reason. It definitely took me a long time to get it exactly how I wanted it, that's for sure.

[7bit]

They are only a couple hours from me, and I drive pretty close to their offices a few times a year.

One of the quirks I've noticed sometimes with xmodmap is that order matters in regards to the modifiers, in terms of your config file. It's quirky, but it usually works in the end. I have noticed that if I use xkb to remap my caps lock and control keys, order matters in regards to remapped control and shift, for whatever reason. It definitely took me a long time to get it exactly how I wanted it, that's for sure.

 Me too! It drove me crazy!

I've got a related question:

It is necessary to run these at startup:
/usr/bin/setkeycodes 71 130
/usr/bin/setkeycodes 72 131
/usr/bin/setkeycodes 74 132
/usr/bin/setkeycodes 6d 133
/usr/bin/setkeycodes 6f 134
/usr/bin/setkeycodes 75 135
/usr/bin/setkeycodes 6c 136
/usr/bin/setkeycodes 5a 137
/usr/bin/setkeycodes 5b 138
/usr/bin/setkeycodes 63 139
/usr/bin/setkeycodes 63 144
/usr/bin/setkeycodes 64 145
/usr/bin/setkeycodes 65 146
/usr/bin/setkeycodes 66 147
/usr/bin/setkeycodes 67 148
/usr/bin/setkeycodes 68 149
/usr/bin/setkeycodes 69 150
/usr/bin/setkeycodes 6a 151
/usr/bin/setkeycodes 6b 152

I did not find a proper way to add them somewhere, such that these lines get executed during the boot, so I just added them to (please don't laugh at me!):

/etc/init.d/fetchmail

I thoght of it being the least harmful place.

[JohnElliott]

I did not find a proper way to add them somewhere, such that these lines get executed during the boot, so I just added them to (please don't laugh at me!):

/etc/init.d/fetchmail

I thoght of it being the least harmful place.

On Ubuntu, it's best to add them to /etc/rc.local.

[7bit]

On Ubuntu, it's best to add them to /etc/rc.local.

 
Thanks I'll give it a try.

[theferenc]

/etc/rc.local is a good place, or better yet, stick them in a script and call them from rc.local. Just remember to make it executable if you go that route.

Wrapping your head around the linux boot process can be pretty hard, especially since there doesn't seem to be a standard. The rc.local (and related scripts) is borrowed from the BSD world in the last few years. Prior to that, there were a series of scripts in the init.d/ directory -- some of which are still used. Very odd. Alas, as with so much in the open source world, there is no standard way of doing it.

[woody]

Wrapping your head around the linux boot process can be pretty hard

It's just different on the different distros.

The rc.local (and related scripts) is borrowed from the BSD world in the last few years. Prior to that, there were a series of scripts in the init.d/ directory -- some of which are still used. Very odd.

Nothing that odd. /etc/init.d contains the various scripts for services and stuff, and /etc/init.d/rc.local is the one executing /etc/rc.local for backwards compatibility.
On Debian distributions, the /etc/rcX.d/ subdirectories contain just symlinks to /etc/init.d for customization of the various run levels.

[theferenc]

The "just different on different distros" bit is exactly what I meant. There is no standard linux boot process. Hence difficult to wrap one's head around it.

That's all I meant. You can learn Redhats, or Ubuntu's, or Debian's, or....

[The Solutor]

/etc/init.d/rc.local is present in most mainstream distros, ubuntu included, the latter just use it to check if /etc/rc.local is present

[woody]

The "just different on different distros" bit is exactly what I meant. There is no standard linux boot process. Hence difficult to wrap one's head around it.

There can't be "standard" linux anyway. Linux is just a kernel and few userland apps. The rest is GNU, distributions, etc., etc.

[theferenc]

Actually, the boot process is entirely about the kernel, up to a point. After that it's all userland stuff. That should very well be a standard, considering how many different applications and processes need to hook into it. It's all hackish, considering how much variation exists.

Anyway, that has nothing to do with the topic at hand. We can always discuss it elsewhere.

[JohnElliott]

Actually, the boot process is entirely about the kernel, up to a point. After that it's all userland stuff. That should very well be a standard, considering how many different applications and processes need to hook into it. It's all hackish, considering how much variation exists.

Standards are great! There are so many to choose from

(In this case, there are roughly two standards -- BSD, which uses /etc/rc.local, and SysV, which uses /etc/init.d/rc.local).

[The Solutor]

(In this case, there are roughly two standards -- BSD, which uses /etc/rc.local, and SysV, which uses /etc/init.d/rc.local).

 
Unix flavors relations and history are always  nice arguments

http://www.levenez.com/unix/


The last word is never said, and now more than before, as we have distros with the GNU/Linux style userland but the BSD or Solaris kernels