devices. This stops machfb0 from trying and failing to attach as
console on my G4 PowerBook. Now, genfb0 will attach as console,
instead.
Apparently, Michael Lorenz made a similar change on the netbsd-4
branch, but it was never committed to -current.
mmap() code.
This and similar requests will be replaced Soon, but these two in
particular should be pulled up to netbsd-4, and to allow doing that
smoothly, we're first introducing the "issuser" version.
Discussed with and okay macallan@.
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