requested by uwe@. These were wrong because they were receiving an
emulcookie yet they were accessops (thus having to receive an accesscookie).
Instead, just handle the WSDISPLAYIO_{GET,PUT}WSCHAR ioctls from the
driver's ioctl accessop.
As this reduces the amount of code needed to handle these operations to
two small functions in each driver, remove the WSDISPLAY_CHARFUNCS kernel
option.
Reviewed by, at least, uwe@ and macallan@. No objections in tech-kern@.
to the screen on which they are being called. The driver cannot guess
this by itself but it is needed to implement, at least, the getwschar and
putwschar functions in the correct place. There are no functional changes
yet.
Tested on i386 (vga, vga_raster, machfb, vesafb), macppc and sparc64.
Suggested and reviewed by macallan@.
problems when more than one mach64 is present
- check memory BARs in mach64_mmap() and adjust allowed ranges in case
something ( XFree86 for instance ) changed them
- disable 'standard' framebuffer mapping at offset 0 on sparc64 because some
Sun/ATI firmware likes to map PCI resources there. May be necessary on other
64bit architectures as well.
firmware likes to put PCI memory resources into this range, notably a Rage
IIc which puts the 2nd register aperture to 0x2000.
This should allow a few graphics chips to work with XFree86 which previously
failed with something like this:
(WW) ATI: PCI/AGP Mach64 in slot 2:5:0 could not be detected!
No devices to configure. Configuration failed.
Thanks to Florian Stoehr for doing most of the work tracking this down.
- fix a panic in mach64_alloc_screen()
- some cleanup
- restrict mach64_mmap() to addresses which belong to it
- mach64_attach now prints bus addresses instead of kernel vm addresses
- initial support for macppc
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
move a few bits around and make adding screens after attach time
actually work.
When not booting as console, try to properly set up the hardware to
get a display nevertheless (XXX - does not yet work on my U5).
#if 0 some unused functions planned for future extensions (to make clear
they are unused now)
offset calculation. Mostly from Bang Jun Young.
Don't call wsdisplay_cnattach unconditionally.
On sparc use OF to decide whether we are console output.
This makes it actually work on my U5 - if only we had a keyboard driver
to produce wskbd events (coming soon).
mrg