Date: Thu, 1 May 1997 23:09:32 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: Doug White <dwhite@resnet.uoregon.edu>, multimedia@freebsd.org Subject: Re: Updated driver (bt848-970424) Message-ID: <19970501230932.46738@ct.picker.com> In-Reply-To: <199705020014.RAA00432@rah.star-gate.com>; from Amancio Hasty on Thu, May 01, 1997 at 05:14:11PM -0700 References: <19970501070521.63393@ct.picker.com> <199705020014.RAA00432@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Amancio Hasty:
|Also, if the X server supports 24bit then the Bt848 can do BGR and drop
|the "A". This can be done by setting the PCI Enable Bytes on the Write
|Risc Instructions . PCI Enable Bytes is field 15:12 . In this case set the
|Bt848 to output 32bit , word swap, byte swap, and set bit 12.
|
|I don't think that Mach64 supports 24bit. Nevertheless, we should plan
|to incorporate the PCI Enable Bytes feature.
Ahh, nice find. So the chip does support a reasonable way of doing
it.
|In your driver patch to support generalized pixel format you forgot to
|have a set of default values for pf_int>color_fmt.
|
|For instance, if I use tv which uses ioctl setgeo the risc program
|actually gets the old value from pf_int->color_fmt
I'm not sure I follow. pf_int is only a name for a temp variable used
to point to a record in the pixfmt_table[], the record for the active pixel
format.
There's an unused pf_int var in common_ioctl which should be removed,
but the other two are initialized when they're declared:
pf_int = &pixfmt_table[ bktr->pixfmt ]
before they're used. bktr->pixfmt is kept up-to-date with the index of the
active pixel format in the table (unless no memory was allocated to the
driver in attach) whether we're still in pixmap format compatibility-mode
or not, so these pf_int's should point to a valid pixfmt_table[] entry.
And so the pf_int->color_fmt reference around line 2317 should give
you the COLOR_FMT register value for the active pixel format (from the
pixfmt_table[]).
Am I missing something?
|In bktr_open add the following:
|
| bktr->pixfmt_compat = TRUE;
|
|This will enable old meteor programs to correctly set their color format.
I think I see where your driving now. That brings up an interesting point.
Looking back at it, the current driver sets compatibility mode in attach(),
and if its ever switched off, it stays off. I agree, this isn't as it
should be.
If we were to switch compatibility mode back on on every open though, if
the open is for a second simultaneous client, this would mess up the first
client's expectations of what the mode is (compatibility on->off). Also
if, at the point of the second open(), the current pixel format didn't
equate with one of the original valid METEOR pixel formats (RGB16, RGB24),
then the pixel format itself would also have to be changed on-the-fly for
it to make sense to be back in compatibility mode. This would be
dangerous; for example, if fxtv is blasting away and Steve's tvremove were
started up, a pixel format change could cause us to write past the end of
the frame buffer or the ximage we're currently blasting in.
With pixel format compatibility mode, I was trying for backward
compatibility with the meteor interface, but the more I think about it it
really just creates more problems than it solves. What about nullifying
the old #define geo.oformat method of specifying the pixel format, and just
adopting the new interface. We don't have so much code already written
that it would be a huge task to change over, do we? I think this would be
the cleanest solution.
Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970501230932.46738>