Port-amiga archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Having trouble with two active wscons drivers, wskbd stops working on console



Hi Frank,

Thank  you very much for your feedback, it was very helpful. I was missing the kbd_cnattach() call in my zzfb_cninit() function.
The zz9k driver was not published yet, as I want to sort out all known remaining issues of my list first. Actually, there is now only one left. More on that below.

The kernel boot message looks like this and is similar to yours now:

kbd0 at mainbus0: CIA A type Amiga
wskbd0 at kbd0: console keyboard
ms0 at mainbus0
wsmouse0 at ms0 mux 0
wsmouse1 at ms0 mux 0
amidisplaycc0 at mainbus0: Amiga custom chip graphics 
wsdisplay1 at amidisplaycc0 kbdmux 1
wsmux1: connecting to wsdisplay1
zz9k0 at zbus0 pa 0x48000000 man/pro 28014/4: MNT ZZ9000 Zorro III (HW: 0.0, FW: 1.13)
zz9k0: Hardware status <Tcore: 38.8 C, Vcore: 1.0 V, Vaux: 1.77 V>
zzfb0 at zz9k0: Framebuffer resolution: 1280x720p60, depth: 8 bpp (8-bit LUT)
wsdisplay0 at zzfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0

So this issue is now solved. Let’s go to the next issue.

My goal is to have the zz9k driver active with CONSOLE as default in WSCONS, so that future NetBSD binary releases include it in the kernel and a potential user does not need to compile a kernel for himself to activate the zz9k driver. 
However, during my extensive tests I noticed that the driver is working in various different setups and configurations, with the exception when there is no ZZ9000 card present in the Amiga, then the kernel will just lock up. I tracked down the issue to my zzfb_cnprobe() function:

void zzfb_cnprobe(struct consdev *cd) {
#ifdef ZZFB_CONSOLE
cd->cn_pri = CN_INTERNAL;
cd->cn_dev = NODEV;
#endif /* ZZFB_CONSOLE */
}

This function is called during kernel startup to prioritize the early console way before the Zorro bus and its cards get probed and initialized. zzfb_cnprobe() will be always called, independently if there is a ZZ9000 installed in the system or not and claim the early console for the zz9k_fb. But if the zzfb_match() fails to find the Zorro card later, there will be no zz9k_fb console available, and the kernel locks up.   
With "cd->cn_pri = CN_NORMAL;” There is no lock-up as the amidisplaycc gets the early console instead. But this is not the behavior I want.
I need a way in zzfb_cnprobe() to determine if a ZZ9000 exists to set CN_INTERNAL or to set CN_NORMAL if not.
I don’t know how to solve this issue, as zzfb_cnprobe() is called long before Zorro bus is active.

I think this is the very same reason why the MNTVA (MNT VA2000) driver has not set the option MNTVA_CONSOLE as default in the WSCONS kernel config file.

Do you have an idea how to solve this issue?

Regards
Alain


On 5. Apr 2023, at 11:48, Frank Wille <frank%phoenix.owl.de@localhost> wrote:

Alain Runa wrote:

[...] but I'm experiencing an issue with the wskbd. It stops
working if two wscons display drivers are active in the kernel. For
example, if I include amidisplaycc (Amiga native) and zz9k_fb (ZZ9000)
in the kernel, the zz9k_fb gets the console at wsdisplay0 but the
console does not respond to any key presses from the keyboard.

The zz9k driver source is not yet available in the NetBSD source tree, or
anywhere?

I'm probably not much of a help, but just to be sure: did you enter the
man/pro ids of your board into the preconftab[] of dev/zbus.c? And did you
register a console-init function at constab[] in amiga/conf.c? And I guess
you also attached wsemuldisplay correctly in your driver's attach function?


Does the driver's console-init function call kbd_cnattach()?


Here the kernel output extract in bad case (amidisplaycc + zz9k_fb):

kbd0 at mainbus0: CIA A type Amiga
wskbd0 at kbd0 mux 1
ms0 at mainbus0
wsmouse0 at ms0 mux 0
wsmouse1 at ms0 mux 0
amidisplaycc0 at mainbus0: Amiga custom chip graphics
wsdisplay1 at amidisplaycc0 kbdmux 1
wsmux1: connecting to wsdisplay1
wskbd0: connecting to wsdisplay1
...
zz9k0 at zbus0 pa 0x48000000 man/pro 28014/4: MNT ZZ9000 Zorro III (HW:
0.0, FW: 1.13)
zz9k0: Hardware status <Ccore: 52.6 C, Tcore: 0.99 V, Vaux: 1.77 V
zzfb0 at zz9k0: Framebuffer resolution: 1280x1024p60,
depth: 8 bpp (8-bit LUT)
wsdisplay0 at zzfb0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0

Just for comparison, I booted my A3000 with Cybervision64 using the WSCONS
kernel. There are some differences, indeed:

kbd0 at mainbus0: CIA A type Amiga
wskbd0 at kbd0: console keyboard
ms0 at mainbus0
wsmouse0 at ms0 mux 0
wsmouse1 at ms0 mux 0
amidisplaycc0 at mainbus0: Amiga custom chip graphics
wsdisplay1 at amidisplaycc0 kbdmux 1
wsmux1: connecting to wsdisplay1
...
grfcv0 at zbus0 pa 0x40000000 man/pro 8512/34
grf5 at grfcv0: width 640 height 480 colors 16
wsdisplay0 at grf5 kbdmux 1: console (default, vt100 emulation), using
wskbd0
wsmux1: connecting to wsdisplay0
grfcv: CyberVision64 with 4MB being used

1. In my case wskbd0 is recognized as "console keyboard".
2. wskbd0 doesn't attach to amidisplaycc0's wsdisplay1.
3. I have "using wskbd0" for my wsdisplay0.

Not sure if this is a problem in your config file or in the driver source.
Maybe you want to show us both?


I see wsmux1 switching to wsdisplay0 but wskbd0 is
not. I'm not sure if it is supposed to do so, but I assume it should.

wskbd0 shouldn't even attach to the non-console wsdisplay1.

--
Frank Wille




Home | Main Index | Thread Index | Old Index