Re: Problems with mach64 on NetBSD/sparc64

2005-10-06 Thread Martin Husemann
On Thu, Oct 06, 2005 at 01:39:10PM -0600, Marc Aurele La France wrote: > No. My preference is definitely to keep the OS out of the way, as much as > possible Ok, but in this case that is not realy possible. You need a OS driver that understands your mmap() call anyway to get the IOMMU mappings c

Re: Problems with mach64 on NetBSD/sparc64

2005-10-06 Thread Martin Husemann
On Thu, Oct 06, 2005 at 09:51:38AM -0600, Marc Aurele La France wrote: > I would venture to guess that a different file descriptor is needed for > every adapter in the system. Yeah, I would prefer to use /dev/fb* for the PCI devices too (this is what is used for SBUS and UPA devices already) - an

Re: Forcing whole screen redraw after unblank

2005-07-14 Thread Martin Husemann
On Tue, Jul 12, 2005 at 01:16:29PM -0600, Marc Aurele La France wrote: > Yes. Try changing FFBSaveScreen() to call the screen's > EnableDisableFBAccess() function. Thanks, this seems to work. I'm still testing it a bit and will make sure that we feedback all our local NetBSD changes soon. Mart

Forcing whole screen redraw after unblank

2005-07-02 Thread Martin Husemann
On some hardware revisions of Sun's FFB frame buffer, it seems the video ram refresh is not handled while the DAC is turned off. Unfortunatley there seems to be no real documentation out, so this is just a guess. What we see now is that after FFBSaveScreen() has turned off the DAC for some time an

Re: sunffb

2005-06-03 Thread Martin Husemann
On Thu, Jun 02, 2005 at 08:55:10PM -0600, Marc Aurele La France wrote: > So you're suggesting this should/will be fixed in NetBSD's kernel? We are evaluating that. I'm not sure the trick in sunffb causes any measurable improvements - but I can't easily test that myself right now. I'll report back

Re: sunffb

2005-05-31 Thread Martin Husemann
On Tue, May 31, 2005 at 08:23:39AM -0600, Marc Aurele La France wrote: > What does NetBSD do with the trap? Re-enable the FPU, restore old FPU state, and retry. No signal to userland is generated. This is the standard lazy fpu saving game - it just did not occur to us that userland code would try

Re: Keyboard handling on non-x86

2005-05-20 Thread Martin Husemann
On Thu, May 19, 2005 at 08:11:25PM -0400, Michael wrote: > And lastly - why does the wscons protocol option require a device name? > Defaulting it to /dev/wskbd should do the trick. I am not sure here. In wscons, there are two fundamentally different ways to access keyboards in the "we have more t