CVS log for src/sys/dev/pci/radeonfbvar.h

Up to [cvs.NetBSD.org] / src / sys / dev / pci

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

s/probaby/probably/ in comments.

first step towards r5xx support:
- no CRTC programming yet, we just use whatever mode the (open)firmware hands
  us
- palette control, fb location etc. all work
- hardware acceleration for character drawing, scrolling etc. works
- hardware cursor works
... tested & still works on various radeons in various macppc machines

Pull up following revision(s) (requested by macallan in ticket #1019):

	sys/dev/pci/radeonfbvar.h: revision 1.21
	sys/dev/pci/radeonfb.c: revision 1.107

reduce stack usage in radeonfb_pickres() and radeonfb_set_cursor()

forgot to commit a header change, again...

forgot to commit a header change, again...

update from HEAD

- unmap registers in WSDISPLAYIO_MODE_MAPPED only if a drm attached
- don't try to touch backlight registers when they're not mapped

Rebase to HEAD as of a few days ago.

sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")

sync with head

implement WSDISPLAYIO_{GET|PUT}CMAP ioctl()s
while there:
- unmap registers and vram only in WSDISPLAYIO_MODE_MAPPED ( so DRM can map
  them ) but not in WSDISPLAYIO_MODE_DUMBFB ( so wsfb can do things that
  require hardware access, like palette and cursor ioctl()s )
- reject ioctl()s that need hardware access if registers are unmapped ( so we
  don't crash instead )
- use the same bit order in cursor sprite images as the other drivers do
with all this, Xorg with wsfb works properly on top of radeonfb

tested on i386 and macppc ( fingers crossed for alpha ;) )

resync from head

clear screen when leaving X so we don't leave garbage in the borders

resync with head

sync with head

don't access registers when they're not mapped
now X works on i386 with radeonfb

sync with head

sync to latest -current.

Pull up following revision(s) (requested by macallan in ticket #132):
	sys/dev/pci/radeonfb.c: revision 1.59
	sys/dev/pci/radeonfbvar.h: revision 1.16
adjust the backlight control interface to match the other drivers ( genfb,
r128fb, voyagerfb etc. ) so the lid_switch script does the right thing
noticed by riz, I thought I fixed that a long time ago

adjust the backlight control interface to match the other drivers ( genfb,
r128fb, voyagerfb etc. ) so the lid_switch script does the right thing
noticed by riz, I thought I fixed that a long time ago

sync to -current

sync to -current

sync to latest -current.

support anti-aliased fonts in 8 bit as well

merge to -current.

cache glyphs in video memory when using anti-aliased fonts on r128fb and
radeonfb

Use pci_aprint_devinfo(9) instead of pci_devinfo+aprint_{normal,naive}
where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.

this should have been committed along with the previous changes in
radeonfb.c

Sync with HEAD.

sync with head

Sync with HEAD

- add support for using compressed images as splash images
- retire SPLASHSCREEN_PROGRESS and SPLASHSCREEN_IMAGE options

Sync with HEAD.

pull in rasops8 for radeonfb, while there defflag a bunch of options and
make them all use the same prefix

when drawing characters by software make sure the engine is idle before
accessing video memory

Sync with HEAD (-D20101022).

sync with head

- fix 8 bit support and run the console in 8 bit for a little extra speed
- fix colour oddities seen occasionally on sparc64
- try to use firmware DAC wiring until we figure out what's wrong
TODO:
- find out why radeonfb gets the DAC wiring ass-backwards on my xvr-100
  while Xorg's radeon driver gets it right
- find out why reverse characters aren't drawn in reverse

tested on macppc and sparc64

sync with head.

forgot to commit that along with radeonfb.c

sync with head.

Sync with HEAD.

Sync with HEAD.

unbork fallout from newlock2 merge:
- reinitializing video after X exits works again
- backlight levels should be right again

unbork fallout from newlock2 merge:
- reinitializing video after X exits works again
- backlight levels should be right again

file radeonfbvar.h was added on branch matt-mips64 on 2007-08-03 05:40:48 +0000

file radeonfbvar.h was added on branch jmcneill-pm on 2007-08-03 05:40:48 +0000

unbork fallout from newlock2 merge:
- reinitializing video after X exits works again
- backlight levels should be right again

Pull up following revision(s) (requested by macallan in ticket #477):
	sys/dev/pci/radeonfb.c: revision 1.10
	sys/dev/pci/radeonfbvar.h: revision 1.4
don't hardcode inverted backlight levels needed on some macppc models

Pull up following revision(s) (requested by macallan in ticket #472):
	sys/dev/pci/radeonfb.c: revision 1.9
	sys/dev/pci/radeonfbreg.h: revision 1.3
	sys/dev/pci/radeonfbvar.h: revision 1.3
add preliminary support for setting backlight levels via ioctl()
from Johan Wallen

sync with head.

Merge newlock2 to head.

don't hardcode inverted backlight levels needed on some macppc models

Sync with head.

add preliminary support for setting backlight levels via ioctl()
from Johan Wallen

sync with head.

sync with head

sync with head.

file radeonfbvar.h was added on branch yamt-lazymbuf on 2006-12-30 20:48:48 +0000

file radeonfbvar.h was added on branch rpaulo-netinet-merge-pcb on 2006-09-09 02:52:19 +0000

file radeonfbvar.h was added on branch yamt-pdpolicy on 2006-09-03 15:24:23 +0000

those should have been committed along with radeonfb.c
doh

Initial import of radeonfb.  Works to some degree on at least some hardware.
Most of the testing was done on MIPS hardware -- it probably needs work before
it will be useful with x86 hardware, and it is probably incompatible with
the X11 server.

"ATI Technologies Inc. ("ATI") has not assisted in the creation of, and
does not endorse, this software.  ATI will not be responsible or liable
for any actual or alleged damage or loss caused by or in connection with
the use of or reliance on this software."

Enjoy!