Keyboards not (recognized? found? functional?) in 4.3/4.4 i386 on amd64

[Jack]

I'm currently on my stock HP box (only until I can build, promise) successfully dual-booting Windows Vista and OpenBSD 4.4 amd64.

Unfortunately, many ports I try to build complain that they're only for i386. (I tried editing that in Makefile, by the way, didn't get me far.) I checked the OpenBSD FAQ. No i386 binary support. Fair enough. But I can run i386 on amd64. Cool.

So I burned a 4.4 i386 disc and booted. The keyboard doesn't work. (Microsoft Natural PS/2.) I also tried the HP PS/2 keyboard shipped with the computer and a USB keyboard. I only get any response at all from the Microsoft Natural: Numlock and F-lock will toggle, but stop even that after a while.

This occurs at Shell/Install/Upgrade prompt. It works fine at the OpenBSD bootloader prompt, so I figure it's narrowed down a bit, there.

I also tried my 4.3 i386 disc; same results.

I'd love to give you guys my dmesg, but, you know, no keyboard.

Has anyone ever seen this?

Thanks.

[jggimi]

I've never seen this.

FAQ 4.15 describes using a serial console ... if you have access to the appropriate equipment you could obtain your dmesg via serial console.

--------------

Since the keyboard works for the second stage bootloader, you could try disabling ACPI:

boot> disable acpi
boot> quit

Not-quite-standard ACPI implementations cause many sorts of problems; yours might be ACPI related. It's a hope, though, not a foregone conclusion.

[Oko]

Originally Posted by Jack

Unfortunately, many ports I try to build complain that they're only for i386. (I tried editing that in Makefile, by the way, didn't get me far.) I checked the OpenBSD FAQ. No i386 binary support. Fair enough. But I can run i386 on amd64. Cool.

That is not true. There are only handful of ports which can be built on i386 but not on AMD64 or Sparc64. They are mostly related to Linux compatibility layer. It is different story if you want to run SGI Mips or VAX but that is due to the broken GNU tool chain. OpenBSD SGI Mips still can run far more free software than Irix. For the record most porters that I know like to use Sparc64 for porting software for many good reasons.

You were trying to install probably win32codecs, Flash, or Opera.
Why do you exactly need to use ports? In OpenBSD world the use of ports is strongly discouraged in favor of binary packages unless packages do not exist due to license issues. Why do you need binary emulator for i386 on AMD64? If you are running mostly i386 software it makes sense to me to run i386 OS unless you have huge amount of RAM but as I said earlier the most things which will not work on AMD64 are either desktop specific or linux compatibility layer related.

For the record, I personally at this very moment run i386, AMD64, and Sparc64.

To answer your second question, I personally have never seen problems you are describing with PS2, USB, or even Mini DIN 8 keyboards (SUN). I have seen installation freezing due to the support for legacy USB devices
which can be easily disabled in BIOS (on i386 and AMD64 obviously since SUN uses Prom)

[jggimi]

In the -current ports tree, there are 53 ports which are ONLY_FOR_ARCHS that include i386 but do not include amd64. Not all of them are Linux; some just can't be built for amd64.

audio/gogo
audio/rio500
audio/wmtune
archivers/rar
chinese/rxvt-big5
chinese/xcin25
devel/ald
devel/jad
devel/jdk
devel/jdk
devel/prc-tools
devel/py-psyco
devel/plib
emulators/freebsd_lib
emulators/ines
emulators/mastergear
emulators/vgb
emulators/wine
emulators/zsnes
games/adom
games/openarena
graphics/cqcam
graphics/win32-codecs
lang/clisp
lang/ezm3
lang/gcc
lang/gcc
lang/gcc
lang/gprolog
lang/jamvm
lang/pm3
lang/sbcl
lang/smlnj
lang/tendra
math/maple
math/maple-share
misc/tpwireless
net/cvsup
net/dss
net/libst
net/openafs
net/ser
palm/isilo
palm/pose
print/acroread
security/l0phtcrack
sysutils/grub
sysutils/libretto-config
sysutils/tphdisk
sysutils/wdsetup
www/mod_frontpage
www/opera
www/opera-flashplugin

Where you see what appear to be dupes -- such as devel/jdk or lang/gcc -- have more than one version in the tree which qualify.

[Oko]

Originally Posted by jggimi

In the -current ports tree, there are 53 ports which are ONLY_FOR_ARCHS that include i386 but do not include amd64. Not all of them are Linux; some just can't be built for amd64.

I didn't say that all of them were Linux related but I said that most were
Include Wine and few others and you will be very close to 53.
53 out of almost 5000 ports confirms what I wrote above. Most ports can be built on AMD64 and Sparc64.

[Jack]

I said, many ports which I tried to build. :P I understand that I can build most things, but when I can't get Opera and clisp, Opera especially, I will begin to consider changing OS platform entirely.

I'll try disabling ACPI.

[Oko]

Originally Posted by Jack

I said, many ports which I tried to build. :P I understand that I can build most things, but when I can't get Opera and clisp, Opera especially, I will begin to consider changing OS platform entirely.

I'll try disabling ACPI.

You need Linux compatibility layer for Opera which only exists for i386.
Additionally Linux compatibility layer doesn't work properly on BSD.MP kernel so if you have core 2 duo processor you will not be able to use both processors and linux comp. That is well documented on mailing lists and there is no fix for now.

Additionally JRE which has plugins for browser is contained in JDK 1.5 which must be compiled from ports due to license issues. Java plugin is non functional in Opera as it is native for BSD and plugin wrappers which will enable you to use those plugins in Opera are only ported to current. Flush Plug in for Opera is Linux Flash 7.0 which works on about 20% of web-sites which do not require version 9.0 or higher.
Sound is non functional as Flush requires ALSA and there is no ALSA emulator in OSS nor anybody is interesting in writing one.

Long story short. OpenBSD is fantastic desktop for serious users but for an average Joe it probably sucks. Safe yourself of frustration and anger towards our community and switch to something else immediately.
YMMV with other BSDs. Probably NetBSD or FreeBSD are "better" choice.
Linux Opera, Flash 10 and Java should run on NetBSD 5.0. On FreeBSD 7.1 you probably can use Opera, Flush 9, and Java plugins but I have not tried to run them .

To be realistic Linux is probably far better choice for Desktop.
My suggestion would be Ubuntu if you are not competent Linux user. If
you are semi competent I personally and lots of other BSD guys like
CentOS (RedHat stable). For the record I do not run Linux period nor other flavors of BSDs. I personally just use OpenBSD.

[Jack]

Hi, thanks for the input.

I don't want Flash or JRE, and while I may have overstated dependence on Opera, it wouldn't be a huge deal if I can't have that, either. Now that I think of it, I'm not that interested in Lisp, and the other 51 packages listed seem like things I could feasibly live without.

I'm not at all angry or frustrated, and don't see myself becoming such any time soon. Sorry if it seemed that way. I'm not interested in an Average Joe's No Kinks Desktop OS. I want a project; OpenBSD is a satisfying one.

Since the keyboard works for the second stage bootloader, you could try disabling ACPI:
boot> disable acpi
boot> quit

It went a bit more like this:

boot> disable acpi
Bad argument 'acpi'
boot> disable apci
boot> quit
boot> boot

(I couldn't remember off the top of my head what ACPI is, and some vague thought flashed through the interear void pertaining to PCI or somesuch, hence such things as APCI. Don't ask.)

It didn't change anything.

I think I'll keep OpenBSD amd64. Better no Opera/plugins/passingly interesting programming languages than no keyboard, hm?

Thanks.

[jggimi]

Excellent summary, Oko.

I use obsd on my personal desktop, except when I have a Flash requirement. Gnash is sometimes discusses as viable, but .. it is only Flash 7 compatible, with some limited Flash 8 capability. And, as you've so eloquently stated, the majority of content requires Flash 9 or Flash 10 capability.

[jggimi]

ACPI: Advanced Configuration and Power Interface

This is what I recommended disabling. There is a standard, but not every BIOS vendor appears to follow it. Disabling the main driver for it in the kernel eliminates many problems. Usually problems related to MP operation, power and cooling, or "hung" kernels during boot.

I can't recall ever hearing of anyone having trouble with PS/2 keyboards under any circumstances. I have only heard of people having trouble with USB keyboards configured (or not) as "legacy" devices.

[BSDfan666]

The problem here is that Oko slightly skewed his instructions..

@jack; at the boot> prompt, type boot -c which will enter the UKC(User Kernel Config) interface.

ukc> disable acpi
ukc> quit

Disabling ACPI may not help, in fact.. you might already have acpi enabled, in that case.. disable apm or pcibios instead.

[jggimi]

That was me, not Oko. You mis- attributed my mistake.

Jack, other than that, BSDfan is correct. Boot with the -c option in the boot loader, the kernel will start loading and drop into the User Kernel Configurator (UKC), where you can disable acpi.

BSDfan recommended disabling APM and leaving ACPI enabled. If the hardware has both, the OS will use APM, ignoring ACPI. So do try with each disabled.

[BSDfan666]

My bad, sorry Oko.

[Oko]

Originally Posted by BSDfan666

My bad, sorry Oko.

No worries body