cfb conversion effort (was Re: Debugging X.org drivers?)

[Roland Mainz]

Adam Jackson wrote:
> On Monday 01 November 2004 02:15, Roland Mainz wrote:
> > Erm... that will be a _huge_ problem as all the print DDX override the
> > GC handing (the fully-vector based DDXs like Postscript and SVGprint
> > should not be a problem... but all the PCL drivers are some kind of
> > crossbreed between bitmap and vector DDX).
> 
> I admit to being out of my depth on this subject.  All I know is, when I did
> the sunleo conversion, the GCOps hackery didn't want to compile, so I dropped
> it on the assumption that it would not affect correctness.  Your drivers may
> be different.
> 
> As an aside, I assume this means the print DDXs don't support Render, correct?

That depends on the rendering model of the PDL being used. For example
PDLs like PDF, SVG and PCL5 would have no problem with native render
support, but for PCL3 and PostScript some emulation needs to be
implemented (there is a nice colorspace stunt which allows alpha
blending with PS but that path is locked due software patents; PCL3 may
be also no problem except that printer-builtin fonts may need extra
hackery as they are rendered on the printer side).

> Where do those DDXes even live?  I don't see them under programs/Xserver/hw.

See xc/programs/Xserver/Xprint/*/

> > > There's an experimental patch to convert sunleo to fb:
> > > http://freedesktop.org/bugzilla/show_bug.cgi?id=1259
> > > which I have received no feedback on as of yet, and I don't have the
> > > hardware to verify it.
> >
> > Did you ask some of the Sun people yet ? They should have the matching
> > hardware... :)
> 
> Not directly.  I'm under the impression that sunleo and sunffb aren't really
> considered interesting anymore.  I'd love to be corrected.

Well, machines like the SPARCstation-10-/-20 (e.g. machines where the
leo fb fits in) are still available on Ebay and due the way Sun built
the hardware in those days (=rock-solid) they may run for the next
twenty years (assuming you're a good owner and care about the machines
(remove dust inside the case every half year etc. :)). sunffb... AFAIK
that was the Creator series (Alan may correct me) and they are still
very widespread these days (like in the Ultra-10, the larger twin of the
Ultra5) ...

> > > The final step would be converting our overlay support to use fb.  I
> > > don't even know where to begin here, largely for lack of hardware.  I see
> > > a couple of functions in the fb layer that look like they're intended for
> > > overlay support.  I've been tempted to just drop our overlay support
> > > altogether to see who complains; my guess is, roughly, nobody.
> >
> > Uhm... I would complain. LOUDLY. :)
> 
> "Our overlay support" here means "the cfb-based xf8_16bpp, xf8_32bpp and
> xf8_32wid modules in the xfree86 DDX".  I'm not talking about ripping all
> overlay support code out of X.  My world view is rather limited to using X to
> put pixels on screens on hardware that people actually have, so I apologize
> for using words like "our" without defining "us" first. ;)

Apology accepted... :))))
 
> I can count the in-tree drivers that use this support on one hand: chips, mga,
> glint, sunffb.  That's not exactly a sweeping majority.

Yeah... but when I buy expensive hardware I expect that such fancy stuff
is supported (see http://store.sun.com/ - V880z with XVR-4000
framebuffer is ~~60000-140000 euro). And AFAIK some applications
(Catia(sp?), Maya etc. come in mind) use overlays...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)