Date: Thu, 01 May 1997 20:23:18 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randall Hopper <rhh@ct.picker.com> Cc: Doug White <dwhite@resnet.uoregon.edu>, multimedia@freebsd.org Subject: Re: Updated driver (bt848-970424) Message-ID: <199705020323.UAA00897@rah.star-gate.com> In-Reply-To: Your message of "Thu, 01 May 1997 23:09:32 EDT." <19970501230932.46738@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
We want to keep compatibility with the meteor. Your current solution is good it just needs a little tiny more thinking and is not hard to check to see if a program had already open the video to device and use that format. The ability to have multiple clients open the video device is nice however it just simply does not work in general. For instance, if I start a vic window and start grabbing yuv422 then proceed to watch tv using fxtv it will mess up my vic window. It is possible to have two video clients provided that they share the exact geometry . In summary, don't allow multiple clients to open the video device and set the bktr compatibility flag on every open. Tnks, Amancio >From The Desk Of Randall Hopper : > 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?199705020323.UAA00897>