Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/sys/dev/wsfb/genfbvar.h

85 lines
2.9 KiB
C
Raw Normal View History

machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h
2007-10-19 15:59:34 +04:00
/* $NetBSD: genfbvar.h,v 1.5 2007/10/19 12:01:24 ad Exp $ */
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
/*-
* Copyright (c) 2007 Michael Lorenz
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of The NetBSD Foundation nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/cdefs.h>
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h
2007-10-19 15:59:34 +04:00
__KERNEL_RCSID(0, "$NetBSD: genfbvar.h,v 1.5 2007/10/19 12:01:24 ad Exp $");
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
#ifndef GENFBVAR_H
#define GENFBVAR_H
#include <sys/param.h>
#include <sys/buf.h>
#include <sys/conf.h>
#include <sys/device.h>
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h
2007-10-19 15:59:34 +04:00
#include <sys/bus.h>
- move all memory mapping into the bus frontend - get rid of macppc-isms like *_mmap() returning physical addresses
2007-04-10 04:14:42 +04:00
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
#include <dev/wscons/wsconsio.h>
#include <dev/wscons/wsdisplayvar.h>
#include <dev/rasops/rasops.h>
#include <dev/wscons/wsdisplay_vconsvar.h>
struct genfb_ops {
int (*genfb_ioctl)(void *, void *, u_long, void *, int, struct lwp *);
paddr_t (*genfb_mmap)(void *, void *, off_t, int);
};
add a callback to change the colour map so now X with wsfb on top of genfb should look right
2007-04-14 23:56:05 +04:00
struct genfb_colormap_callback {
void *gcc_cookie;
void (*gcc_set_mapreg)(void *, int, int, int, int);
};
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
struct genfb_softc {
struct device sc_dev;
struct vcons_data vd;
struct genfb_ops sc_ops;
struct vcons_screen sc_console_screen;
struct wsscreen_descr sc_defaultscreen_descr;
const struct wsscreen_descr *sc_screens[1];
struct wsscreen_list sc_screenlist;
add a callback to change the colour map so now X with wsfb on top of genfb should look right
2007-04-14 23:56:05 +04:00
struct genfb_colormap_callback *sc_cmcb;
add shadow fb support now genfb is actually usable even on slow PCI framebuffers. Yay Jared :)
2007-08-05 03:51:37 +04:00
void *sc_fbaddr; /* kva */
void *sc_shadowfb;
- move all memory mapping into the bus frontend - get rid of macppc-isms like *_mmap() returning physical addresses
2007-04-10 04:14:42 +04:00
bus_addr_t sc_fboffset; /* bus address */
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
int sc_width, sc_height, sc_stride, sc_depth;
size_t sc_fbsize;
int sc_mode;
u_char sc_cmap_red[256];
u_char sc_cmap_green[256];
u_char sc_cmap_blue[256];
};
- move all memory mapping into the bus frontend - get rid of macppc-isms like *_mmap() returning physical addresses
2007-04-10 04:14:42 +04:00
void genfb_init(struct genfb_softc *);
add genfb, a generic framebuffer console driver that's configured via device properties - all it needs is width and height in pixels, stride in bytes, depth in bits and the framebuffer address. Features: - unaccelerated fb console with colours and virtual consoles - split into console handling and bus frontend - so far there is only a PCI bus frontend which allows to mmap BARs belonging to the graphics controller, others should be easy to add. TODO: - find an opaque way to change the palette ( probably pass a function pointer as property ) since this would need to call some firmware interface which is pretty much always MD - find a clean way to mmap the framebuffer, just returning the physical address works on macppc but not on other architectures. Problem is, that we cannot rely on the address being a bus address - on macppc it is, but for instance on sparc64 it's not.
2007-04-07 07:41:26 +04:00
int genfb_attach(struct genfb_softc *, struct genfb_ops *);
#endif /* GENFBVAR_H */