Jeff Epler | 9 Jan 18:26 2003
Picon

it's been nice

XFree86 is the new all purpose list.I've really enjoyed lurking on this list and hearing about the development
of render and related libraries.

With the move to consolidated lists, I won't be able to do so anymore --
there's just too much irrelevant stuff for me to read.

I don't understand xfree86.org's reasons for this list consolidation, but
if it's what they want to do..

Jeff
Adam Majer | 31 Dec 06:49 2002

DGA 2.0, GLX and OpenGL

Hi all,

Sorry for the crossposing but if someone knows 
the answer to the following, could you please
cc me with the answer?

Is it possible to set up OpenGL using DGA to switch
video modes? I tried this and I get:

Video init (DGA): DGA found...
Video init (DGA): DGA Version 2.0
640x480 24 bits at 85.0Hz  score: 19360096.00
640x480 16 bits at 85.0Hz  score: 20000096.00
Selected mode: 16
Asked for: 640x480 16 bits
      Got: 640x480 16 bits at 85.008003Hz
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  128 (XFree86-DRI)
  Minor opcode of failed request:  7 ()
  Value in failed request:  0x3e
  Serial number of failed request:  35
  Current serial number in output stream:  35

The BadValue comes when I try making the GLX context
current..

dev is pointer from the XDGASetMode and dev->pixmap is valid
Xlib pixmap.

and the rest is called after the mode is set...
(Continue reading)

David Dawes | 3 Jan 18:35 2003

XFree86 mailing list consolidation

XFree86 is the new all purpose list.st of the public XFree86 mailing lists are being consolidated into a
single list -- "XFree86 <at> XFree86.org".  This new list is open for
subscription at <http://www.xfree86.org/mailman/listinfo/xfree86>.
Subscriptions from the old lists won't automatically be moved to the
new list, so people will have to go there to join the new list.  There
are no subscriber-only posting restrictions, but there is automated
virus/spam filtering.

The four lists being migrated at this time are newbie, xpert, render,
and neomagic.  During a 1 week transition period, mail to these lists
will be delivered to both the old and new lists.  After the transition
period, the old lists will be disabled, and messages sent to them will
be transparently redirected to the new list.

Happy New Year!

David
--
David Dawes
Release Engineer/Architect                      The XFree86 Project
www.XFree86.org/~dawes
Papp Zoltán | 27 Dec 10:02 2002
Picon

compaq presario 2805EA

Is there anybody, who can use compaq presario 2805EA laptop with any linux
distrib
without vertical screen screw (ATI Mobility M7).
Will future X versions support this videochip?

Thanx, and happy hollyday for You, all!

Best regards,
PAZO
Hadi Torabi | 16 Dec 14:51 2002
Picon

X-video

Hello,

We have a board with Geode processor. Does Xv suppotrs geode's. If yes how can we use it?! And if no what should I do to increase my Xine performance?!

Thanks


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Andreas Volz | 24 Dec 15:18 2002
Picon

Mailing List Achiv?

Hello,

is there still someone listening to this list? Are the up to now written
Mails from this list are archived somewhere?

Thanks
Andreas
Abhijeet Ghosh | 16 Dec 23:04 2002
Picon

multiple graphics cards

Hi,

Can anyone please let me know if its possible to have a PCI bus graphics card in addition to an AGP bus graphics card on one machine? I have been told that one could run two separate Xservers for each card. If anyone has any experience with this kind of thing, please kindly advice.  

Thank you,

___________________________

Abhijeet Ghosh
Graduate student,
Department of Computer Science,
SUNY - Stony Brook, NY - USA.
http://www.cs.sunysb.edu/~abhijeet
___________________________

Add photos to your messages with MSN 8. Get 2 months FREE*.
Vadim Plessky | 11 Dec 19:28 2002
Picon

OT: shipments of LCD panels rising


http://www.digitimes.com/NewsShow/Article.asp?datePublish=2002/12/05&pages=PR&seq=201
...
Chunghwa Picture Tubes (CPT) registered the strongest growth by shipping 
428,000 15-inch panels, 6,000 18-inch panels and a small amount of 17-inch 
panels. However, the company reportedly sold its 15-inch LCD monitor panels 
at less than their unit production cost of US$170.

Chi Mei Optoelectronics (CMO) was able to ship 200,000 17-inch panels, which 
should help to improve its sales and average profit margin amid the generally 
declining price trend. The company plans to begin shipments of 20 to 30-inch 
LCD TV panels and mobile phone panels in the first quarter of next year

http://www.digitimes.com/NewsShow/Article.asp?datePublish=2002/12/11&pages=07&seq=41
...
Contract prices for 15 and 17-inch TFT LCDs scheduled for shipment this month 
reportedly have been lowered to US$160-170 and US$260-270, respectively, each 
down by US$15 from last month, reported the Nihon Keizai Shimbun.

While the price for 15-inch LCD monitor panels has fallen below many panel 
producers' costs, industry observers expect the price decline to slow 
considerably beginning early next year.

***
So, does dream come true?
With prices of 15" LCDs at $170-$200 range there is a good possibilities that 
typical office desktop installs would have LCD (not CRT) monitor in 2003.

As configuration of LCD displays in XFree86 is pretty easy (all modes are 
known, size of viewable area is fixed, etc.), and sub-pixel geometry is 
known, LCD display makes perfect fit for typical Linux/XFree86 Desktop.

And 20"-30" LCD TVs (mentioned above) sound very promising, too.
Has someone tried one of those?  Or 9Megapixel (200dpi) LCD panel from 
Viewsonic (based on IBM developments)?
Most likely, I would have good budget for 2003, and certanly would plan one of 
those things for myself.

--

-- 

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net
My KDE page
http://kde2.newmail.ru  (English)
KDE mini-Themes
http://kde2.newmail.ru/themes/
Juliusz Chroboczek | 10 Dec 18:17 2002
Picon

Renderised gs: some timings

Hello,

For your enjoyment, here are a few timings of GS using a render-based
driver.  In the tables below, x11 is the stock X11 driver in
ghostscript (run with -dNOPLATFONTS), x11alpha is the alpha-aliasing
driver that uses client-side backing store and 4-bit AA, xr is the
render-based driver with AA disabled, and xralpha is the same driver
with 4-bit alpha enabled.

You should take those timings with a pinch of salt, as many driver
functions are not implemented yet.  In particular, the only driver
methods implemented are bitmap pushing (mono colour expanding, colour
through an alpha mask, and opaque colour blits) and opaque rectangles.
All rendering will be either done on the client side and pushed
through one of the above or else converted into spans rendered using
XFillRectangle.

A server-side glyph cache is implemented (256 mono glyphs and 256
eight-bit glyphs), which is only used for small glyphs.

The driver is completely untuned.  In particular, all format
conversions (bit-order conversion, 4->8 expansion, etc.)  are done the
naive way.

ea-ea.ps is a fourteen-page long paper typeset with Type 1 versions of
the cmr fonts.  It gets very high hits from the server-side glyph
cache.

waterfal.ps is the glyph waterfall included with gs.  Because every
glyph is distinct, it gets no hits whatsoever from the glyph cache.

escher8.ps is eight copies of the escher.ps demo included with gs.
It's geometry rendering only.  In the case of xr, all rendering is
converted into spans which are sent to the server using XFillRectangle
(the x11 driver uses trapezoids and thick lines).  In the case of
xralpha, everything is rasterised in the client and sent to the server
using XPutImage followed by XRenderComposite(PictOpOver).

Note that these times include gs's startup time (0.2 s) and any
interpreter and font loading overhead.

ea-ea.ps:
  x11: 1.3s  xr: 1.5s
  x11alpha: 3.4s xralpha: 1.9s

waterfal.ps:
  x11: 0.4s  xr: 0.5s
  x11alpha: 0.8s xralpha: 0.5s

escher8.ps:
  x11: 1.7s  xr: 1.9s
  x11alpha: 5.9s  xralpha: 7.6s

I'm a little disappointed by the non-AA timings for the text-rich
documents.  The bad performance of escher.ps with both xr and xralpha
is as expected.

                                        Juliusz
Juliusz Chroboczek | 10 Dec 17:25 2002
Picon

Render bug -- glyphs larger than 256 pixels accross.

Hello,

The attached code attempts to typeset a LEN x 1 sized eight-bit AA
glyph.  By default, LEN is 255, and everything works fine.  If LEN is
changed to be 256, nothing is rendered.

Playing with the op seems to imply that in the latter case the alpha
channel is consistently taken to be all zeroes.

I'm using XFree86 4.2.0 (as patched by Debian) on x86, visual is
24/32.  The problem is reproducible on Savage and ATI Rage.

                                        Juliusz
#include <stdlib.h>
#include <stdio.h>
#include "Xlib.h"
#include "Xrender.h"

#define LEN 255

int
main()
{
    Display *dpy;
    Screen *scr;
    XSetWindowAttributes swa;
    Window window;
    Visual *visual;
    XRenderPictFormat templ;
    XRenderPictureAttributes pictattr;
    XRenderPictFormat *pictformat;
    Picture picture;
    XRenderPictFormat *gpictformat;
    Pixmap tpixmap;
    Picture tppicture;
    XRenderPictFormat *tpictformat;
    GlyphSet glyphset;
    XGlyphInfo ginfo;
    Glyph g;
    XRenderColor rcolor;
    XEvent event;
    int i;
    char buf[2048];

    dpy = XOpenDisplay(NULL);
    if(dpy == NULL)
        exit(1);

    scr = DefaultScreenOfDisplay(dpy);
    visual = DefaultVisualOfScreen(scr);
    pictformat = XRenderFindVisualFormat(dpy, visual);

    templ.type = 1;
    templ.depth = 8;
    templ.direct.redMask = 0;
    templ.direct.greenMask = 0;
    templ.direct.blueMask = 0;
    templ.direct.alphaMask = 0xFF;
    templ.direct.alpha = 0;
    gpictformat = 
        XRenderFindFormat(dpy,
                          (PictFormatType | PictFormatDepth |
                           PictFormatRedMask | PictFormatGreenMask |
                           PictFormatBlueMask |
                           PictFormatAlpha | PictFormatAlphaMask), 
                          &templ, 0);
    if(gpictformat == NULL)
        exit(1);

    swa.event_mask = ExposureMask;
    swa.background_pixel = WhitePixelOfScreen(scr);

    window = XCreateWindow(dpy, RootWindowOfScreen(scr),
                           100, 100, 700, 300, 0,
                           DefaultDepthOfScreen(scr),
                           InputOutput, visual,
                           CWEventMask | CWBackPixel, &swa);

    picture = XRenderCreatePicture(dpy, window, pictformat, 0L, &pictattr);

    tpixmap = XCreatePixmap(dpy, window, 1, 1, 32);
    templ.type = 1;
    templ.depth = 32;
    templ.direct.redMask = pictformat->direct.redMask;
    templ.direct.red = pictformat->direct.red;
    templ.direct.greenMask = pictformat->direct.greenMask;
    templ.direct.green = pictformat->direct.green;
    templ.direct.blueMask = pictformat->direct.blueMask;
    templ.direct.blue = pictformat->direct.blue;
    templ.direct.alphaMask = 0xFF;
    tpictformat = XRenderFindFormat(dpy,
                          (PictFormatType | PictFormatDepth |
                           PictFormatRedMask | PictFormatRed |
                           PictFormatGreenMask | PictFormatGreen |
                           PictFormatBlueMask | PictFormatBlue |
                           PictFormatAlphaMask), 
                          &templ, 0);
    if(tpictformat == NULL)
        exit(1);
    pictattr.repeat = 1;
    tppicture = XRenderCreatePicture(dpy, tpixmap, tpictformat,
                                     CPRepeat, &pictattr);
    rcolor.red = 0xFFFF;
    rcolor.green = 0;
    rcolor.blue = 0;
    rcolor.alpha = 0xFFFF;
    XRenderFillRectangle(dpy, PictOpSrc, tppicture,
                         &rcolor, 0, 0, 1, 1);
    glyphset = XRenderCreateGlyphSet(dpy, gpictformat);
    for(i = 0; i < 512; i++)
        buf[i] = i;
    ginfo.width = LEN;
    ginfo.height = 1;
    ginfo.x = 0;
    ginfo.y = 0;
    ginfo.xOff = 0;
    ginfo.yOff = 0;
    g = 0;
    XRenderAddGlyphs(dpy, glyphset, &g, &ginfo, 1, buf, LEN);
    XMapWindow(dpy, window);
    while(1) {
        XNextEvent(dpy, &event);
        if(event.type != Expose)
            continue;
        XRenderCompositeString8(dpy, PictOpOver,
                                tppicture, picture,
                                gpictformat, glyphset,
                                0, 0, 100, 200, "\0", 1);
    } 
    return 0;
}
Juliusz Chroboczek | 8 Dec 22:58 2002
Picon

Struggling with render performance

Hello,

I've started playing with a version of Ghostscript that uses Xrender
for rendering, and I'm finding a few problems with performance.  I'm
probably doing something wrong.

In my current setup, I'm using an 8:8:8 window and a 8:8:8:8 backing
pixmap.  Once in a while, I blit the modified area of the pixmap onto
the window by using XRenderComposite with PictOpSrc.

Although the pixmap and the window have the very same pixel format (up
to the absence of alpha in the window), I'm finding the performance of
the blit somewhat disappointing.  Am I using the wrong approach?

When gs's upper layers try to non-AA render something that my driver
doesn't implement, they convert the primitive into spans and
repeatedly invoke a method which does a XRenderFillRectangle with
PictOpSrc; I then channel the drawing to both the pixmap and the
window to avoid having to do a blit.  Is that okay, or do you
recommend working with XDrawRectangle on the underlying drawables?

When the same thing happens with AA rendering, the method that gets
invoked is the very same one as the one that is used when doing AA
text; thus, I put the span into a glyphset, and do
XRenderCompositeString8 on a one-character eight-bit-deep string with
PictOpSrc and a 1x1 pixmap as src.  Is that okay, or should I avoid
manipulating glyphsets when I know that the given mask won't be
reused.

In that method, I'm seeing rendering artifacts when the span is over
256 pixels wide; the rendering appears to be cut at an abscissa of
256.  While I haven't isolated the code yet, I'm wondering if that
could be a known bug in 4.2.0.  (Keith, does xscope dump render, by
the way?)

(In case you're worried: a different method will be used when I
implement the high-level compositor interface, but I want to get the
current code working first.)

Finally, is it possible to add an external alpha channel to an
existing pixmap?  I'm thinking of dynamically allocating the alpha
channel on the first non-opaque rendering operation in cases when the
window's pictformat has no associated pictformat with good alpha.

Thanks a lot,

                                        Juliusz

Gmane