Re: radeon 2d engine and alpha blending
On Fri, 2003-11-21 at 04:39, Alex Deucher wrote: I realize that I could attempt to use it for render accel, but I was hoping to tie it into Keithp's compositing extension (http://www.freedesktop.org/Software/TranslucentWindows) to support alpha blended windows, not just hw accelerated AA text. What else would xcompmgr be using, if not RENDER? [...] I may need to use the 3d engine, 'May'? which then gets into a whole new can of worms with regard to state and locking. I doubt it'll be all that bad, and anyway, you can worry about that once you have something working... Transparent bitblits are supported by XAA's normal bitblit functions, how are these used? are there any apps that use them? render? Plain old ScreenToScreen copy. trans_color (the last argument to the SetupScreenToScreenCopy function) holds the (source) color which is handled to be transparent. It's as simple as that. (hint, hint: sis310_accel.c) And MD is right, it's not a plain transparent bitblit, it's colorkeyed in fact (but only using one color key, not a range). Isn't used very often, though. Thanks for the pointers. I'll take a look. It may not be worth the effort. Colour-keyed blits have been implemented in the radeon driver for ages... problem is, they're not what you'd like them to be. :) (XDirectFB uses them for SHAPE quite nicely though) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: new input driver for Packard Bell (UC-Logic) tablet
--- Jonathan Hough [EMAIL PROTECTED] wrote: (message resent as it didn't seem to get through yesterday) I have written a new input driver for my unsupported graphics tablet. It's badged as a Packard Bell GT100, but /proc/bus/usb/devices says it's really a UC-LOGIC WP8060U. I have the driver compiled and working on my system, and I'd like to submit it for inclusion in XFree86. This will be the first time I've submitted a new module to an Open Source project, so can someone advise me on what to do next? Open a bug on http://bugs.xfree86.org/ and post your patch there. One specific question - I've based my driver on the Wacom driver, but there have been numerous changes (it wouldn't work with the Wacom tablet now). Should I change the copyright statement to my own name, with credit to the authors of the Wacom driver, or leave it as it is and add myself as a co-author? It's generally accepted practice to put put your name on the copyright even if you based the code on another driver since you were the one to put it together and get it working for your hardware. I have cut out most of the Wacom code that isn't relevant to this tablet, but I'm still making some finishing touches on cleaning it up. Sounds good. I look forward to seeing your patch. Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: new input driver for Packard Bell (UC-Logic) tablet
On Fri, 21 Nov 2003, Alex Deucher wrote: --- Jonathan Hough [EMAIL PROTECTED] wrote: One specific question - I've based my driver on the Wacom driver, but there have been numerous changes (it wouldn't work with the Wacom tablet now). Should I change the copyright statement to my own name, with credit to the authors of the Wacom driver, or leave it as it is and add myself as a co-author? It's generally accepted practice to put put your name on the copyright even if you based the code on another driver since you were the one to put it together and get it working for your hardware. something like that. The attribution should be a separate entry (e.g., line or paragraph) to avoid confusing it with the original one. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon 2d engine and alpha blending
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Fri, 2003-11-21 at 04:39, Alex Deucher wrote: I realize that I could attempt to use it for render accel, but I was hoping to tie it into Keithp's compositing extension (http://www.freedesktop.org/Software/TranslucentWindows) to support alpha blended windows, not just hw accelerated AA text. What else would xcompmgr be using, if not RENDER? I dunno... I just never really looked at render too much. As I recall back when it was first everyone wanted to do compositing with it and the general reponse was that it was only for AA text. I guess we were just lacking the compmgr and damage extention at the time... [...] I may need to use the 3d engine, 'May'? which then gets into a whole new can of worms with regard to state and locking. I doubt it'll be all that bad, and anyway, you can worry about that once you have something working... Yeah I know. I doubt it'll be that bad. It's just that I've gotten to understand the 2d engine pretty well (or at least I think I do) and the 3D engine seems like this daunting thing out there. However looking at the code and databooks it doesn't look that complicated, I just need to sit down and do it some day. I'm just trying to get the most bang from my limited time... Transparent bitblits are supported by XAA's normal bitblit functions, how are these used? are there any apps that use them? render? Plain old ScreenToScreen copy. trans_color (the last argument to the SetupScreenToScreenCopy function) holds the (source) color which is handled to be transparent. It's as simple as that. (hint, hint: sis310_accel.c) And MD is right, it's not a plain transparent bitblit, it's colorkeyed in fact (but only using one color key, not a range). Isn't used very often, though. Thanks for the pointers. I'll take a look. It may not be worth the effort. Colour-keyed blits have been implemented in the radeon driver for ages... problem is, they're not what you'd like them to be. :) (XDirectFB uses them for SHAPE quite nicely though) Yeah, I'm starting to understand how all this stuff fits together now. Is there anyway xfree86 could use them for the shape extension? or does it already? Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Generalizing the XCSecurity CheckAccess callback
I'm working on an extension for X as part of the Security-Enhanced Linux project. The XCSecurity extension has a callback function in the client structure that gets called whenever a resource lookup is done on behalf of the client. I'd like to add functionality to the XCSecurity extension to allow other extensions (e.g. mine) to register callbacks for this event. My plan is to add a CallbackListPtr to XCSecurity and functions for other extensions to use to add/remove callbacks to it. Then I just have to make sure the CheckAccess structure member gets called for all lookups (not just untrusted ones), and have that function call all the callbacks besides doing the XCSecurity stuff (checking the trustlevel and all that). Comments/critiques on this idea would be appreciated. -- Eamon Walsh [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86, XAA and COMPOSITE
Optimally this would be done completely with OpenGL using pbuffers and texture hardware. Alex --- Mark Vojkovich [EMAIL PROTECTED] wrote: Current XAA only supports rendering to a single surface where the location to draw at is indicated by pDrawable-x and pDrawable-y. It doesn't know anything about alternate storage locations for windows. And it probably blows all the GC validation out of the water because drawables that it previously thought were always in hardware (windows), are now possibly in system memory. My first impression is that expecting GCOps to redirect to Pixmaps is the wrong implementation and the Window-Pixmap redirection should have happened transparently in a wrapper higher up. Also, how is OpenGL supposed to work with something like this? Mark. On Thu, 20 Nov 2003, Michael Matz wrote: Hi, [please leave me CC'ed, I'm not (yet?) subscribed to this list] I ported over Keith Packards new extensions (COMPOSITE and DAMAGE) from the freedesktop Xserver to Xfree86, which seems to have worked more or less. See http://ktown.kde.org/~matz/BuntX.png which shows XFree86 on a mga card, with those extensions (plus XFIXES) and xcompmgr running for the translucent windows with shadow. To make this work I had to disable XAA, though (i.e. Accel off). If I leave it on, the windows content is totally off (i.e. I get shadows around where the windows logically are, and I can move them, just the content shows a mixture of background from somewhere else, or anything, just not the real content). The way COMPOSITE works is by allocating a Pixmap for each toplevel window, and setting it with pScreen-SetWindowPixmap. It then expects the rest of the xserver to render into these pixmaps for all normal render requests, and provides a mean to copy those pixmaps back to the screen (possibly in fancy ways). Of course this will be fast only if that pixmap lies in offscreen video-mem and the graphic chip is used for rendering into it (although theoretically it all works if it's somewhere else, it just becomes slower). So, when XAA is active, one of the following things goes wrong: * it doesn't render into the window pixmap * it's not able to correctly blit back the window pixmap to the screen * something else ;) My question: is XAA supposed to handle the case of rendering into such a pixmap tacked to a window at all, or do I have to implement some magic there? I looked at xaa/*.c but I have some difficulties understanding all the different kinds of indirections ;-) At least I couldn't find a definite place where the rendering GCOps would look at GetWindowPixmap, like for instance the fb driver does (through the use of fbGetDrawable). In a first iteration I would probably already be satisfied if not the chip is used to render into the pixmap, but simply calls into the upper layers of the server to do that, i.e. basically Graphical-xaa-op (drawable) if (drawable == WINDOW � drawable-has-window-pixmap) return call-upper-op (drawable-GetWindowPixmap); /* or call-upper-op (drawable) ? */ do accelerated stuff on drawable Is it indeed the case that this isn't expected by XAA at all (although the possibility of having a window pixmap is already in the server before Keiths additions, Get/SetWindowPixmap seems to be part of XFree86 since 1998). Sorry if those are stupid questions, I'm a GCC hacker in my day job, I just have vacation ;-) Someone wants to lend me a helping hand? Btw. my current patch is at http://ktown.kde.org/~matz/fdo-2-xf86-5.diff . Ciao, Michael. __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86, XAA and COMPOSITE
On Fri, Nov 21, 2003 at 10:09:11AM -0800, Alex Deucher wrote: | Optimally this would be done completely with OpenGL using pbuffers and | texture hardware. It's also worthwhile to remember that using OpenGL buys you a lot of other functionality that otherwise you'd have to reinvent -- things like projective transformations, mapping images onto arbitrary shapes, acceleration for colorspace conversion and color adjustment, etc. There's something to be said for having a simpler interface, but it's a loss in the long run if you eventually reinvent what already exists and require driver writers to support two different ways of doing the same thing. Allen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Support of Microsoft IntelliMouse Wireless Explorer 2.0 with tilt wheel
Hi there, I'd like to ask if xfree86 mouse driver supports this mouse and if yes how to configure it? If no, is there any plan to add the support? When it's going to be ready? I use SuSE 4.3.0 Xserver and I run KDE 3.2.0 CVS Thanks. Best regards, Ing. Jozef Sakalos, [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Conversion of README's to DocBook Format
Greetings, I have been laboring in the background for about 18 months converting the README files from linuxdoc format to DocBook format. I believe I have nearly completed that effort. My efforts are currently stored in a separate cvs instance at XFree86.Org. During that time, some bit-rot of the documentation has occurred, but it should be a very small task to bring the DocBook versions to currency. It is time to begin submitting the infrastructure necessary to support the conversion (tools, DTD, stylesheets, etc) to XFree86 for inclusion into the main cvs instance. Since this involves over 1800 files, submitting them via Bugzilla or mailing lists as individual files is quite impractical (I have a gift for seeing the obvious) :-] I would like group the files into logical components and submit them as tar files. David Dawes and I have exchanged emails on the doc list and have come to an agreement as to placement of the logical groups in cvs. To whom or to where should I submit the tar files? After the infrastructure is completely in place, I will begin submitting the converted README files. Since there will be some stylistic changes in the output, I plan to start by submitting the converted XFree86 4.4 Release Notes, the New Design document, and the README.ati document. I chose these because they represent different styles of documents and will present good examples for discussion of any requested changes to style. Questions and comments are encouraged. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fwd: [Bug 887] Calling XInitThreads and linking with pthread library causes deadlock in Xprint]
Hi! Can anyone review the patch in bug 887 and commit it to the CVS if it is OK, please ? Original Message Subject: [Bug 887] Calling XInitThreads and linking with pthread library causes deadlock in Xprint Date: Wed, 19 Nov 2003 05:02:43 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=887 --- Additional Comments From [EMAIL PROTECTED] 2003-19-11 05:02 --- Created an attachment (id=817) -- (http://bugs.xfree86.org/attachment.cgi?id=817action=view) Proposed fix for 2003-11-10-trunk -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You reported the bug, or are watching the reporter. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: [Bug 887] Calling XInitThreads and linking with pthread library causes deadlock in Xprint]
On Sat, Nov 22, 2003 at 02:43:33AM +0100, Roland Mainz wrote: Hi! Can anyone review the patch in bug 887 and commit it to the CVS if it is OK, please ? I committed it last night, and it is included in the 4.3.99.16 snapshot that was tagged last night. I recommend the [EMAIL PROTECTED] list. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Conversion of README's to DocBook Format
On Fri, 21 Nov 2003 18:33:49 -0600, John Himpel [EMAIL PROTECTED] wrote: Greetings, I have been laboring in the background for about 18 months converting the README files from linuxdoc format to DocBook format. I believe I have nearly completed that effort. My efforts are currently stored in a separate cvs instance at XFree86.Org. Yes that's xml-work, right? Couldn't we just move it over to the public CVS? Since this involves over 1800 files, submitting them via Bugzilla or mailing lists as individual files is quite impractical (I have a gift for seeing the obvious) :-] I would like group the files into logical components and submit them as tar files. David Dawes and I have exchanged emails on the doc list and have come to an agreement as to placement of the logical groups in cvs. To whom or to where should I submit the tar files? Couldn't you just send them here? I think that would work. Questions and comments are encouraged. Do you have any documentation on how to read this docbook stuff? Are special utiliites required? How do they become HTML for Web browsing or is that a separate issue? I'm glad to hear that the Doc Team Leader finally finished his magnus opus. Could a sample page be sent here so we could start discussing it and seeing what this is all about? Best Regards, Georgina ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bugzilla
http://www.bugzilla.org/ [ 2003 Nov 09 ] Bugzilla 2.17.6 Released We had a small oops with the 2.17.5 release, whereas one of the new features that was introduced also introduced a new security hole. For the full details, read the security advisory. Note that this affects version 2.17.5 only and the current stable version 2.16.4 is not affected. Since this is the development branch, there have been other checkins besides the security fix. For a complete list, click the 2.17.5 2.17.6 link on the changelog page. Version 2.17.6 is available on the download page. I noticed today this notice. Does this matter to us as we are 2.17.4 or not? And if so, who takes care of this? Georgina ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Conversion of README's to DocBook Format
On Fri, Nov 21, 2003 at 10:31:42PM -0500, Georgina Economou wrote: On Fri, 21 Nov 2003 18:33:49 -0600, John Himpel [EMAIL PROTECTED] wrote: Questions and comments are encouraged. Do you have any documentation on how to read this docbook stuff? While not directed at me, I do have some experience in converting a large scale documentation project to docbook. I'm glad this is being done -- DocBook is, IMHO, the best of the currently available markup formats for large amounts of information. It can render the input documents into a variety of formats... Are special utiliites required? For viewing and editting the docbook source files, all you need are a text editor, like vi (or emacs). There are certainly tools available that make doing the markup more automatic, but it certainly can be done in something as simple as a text editor. How do they become HTML for Web browsing or is that a separate issue? Typically, this is done with either something like XSLT (I think that's the right one -- I've not used this one), or something like a pipeline with OpenJade, and a bunch of other tools. When I did it last, it was involved to get the entire documentation tool-chain up and running, but once that was done, rendering the same document source into HTML, PDF and PostScript was just a matter of typing make. In many ways, if you're good at doing HTML, you're going to have no problems with doing DocBook markup. Some of the shortcuts that people often take in HTML (and most browsers are happy enough to display) don't work in SGML. -Kurt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
FW: RE: [Bug 537] wacom usb tablet uses wrong screen borders
Title: FW: RE: [Bug 537] wacom usb tablet uses wrong screen borders I am wondering if Egbert is taking vacation or something.Is there anyone else can take care of my patch? Thanks. Ping -Original Message- From: Ping Cheng To: '[EMAIL PROTECTED]' Sent: 11/14/03 3:50 PM Subject: RE: [Bug 537] wacom usb tablet uses wrong screen borders Hi Egbert, I didn't see my changes in http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/input/wa com/xf86Wacom.c. Is there anything wrong with my patch? I really hope itcan getinto XFree86 4.4 release. Please contact with me if there is anything thatI can help. Thanks, Ping -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 11, 2003 4:11 AM To: [EMAIL PROTECTED] Subject: [Bug 537] wacom usb tablet uses wrong screen borders Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=537 [EMAIL PROTECTED] changed: What |Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|ASSIGNED |NEW --- Additional Comments From [EMAIL PROTECTED] 2003-11-10 07:11 --- Thanks. I'll check and commit your patch. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: FW: RE: [Bug 537] wacom usb tablet uses wrong screen borders
On Fri, Nov 21, 2003 at 08:17:45PM -0800, Ping Cheng wrote: I am wondering if Egbert is taking vacation or something.Is there anyone else can take care of my patch? I think he is. One problem with the patch is that modules are not permitted to include xf86Optrec.h. The structures there are opaque to everything except the parser layer, and could change with a different parser layer. strcasecmp() isn't a reliable way to compare option names because option naming is more flexible than just case-insenstive. Use xf86NameCmp() instead. It also isn't permissible for drivers to be writing to files. If xsetwacom needs to know the device options, maybe it could link to the parser library itself and read the XF86Config file directly. I'm not clear on what else data is written out to files for. If data needs to be passed between a driver and an application, then a client-server communication mechanism should be used, either via an existing mechanism or via a new extension. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fwd: [Bug 898] New: mkfontscale creates ISO8859-15 lines for Type1 fonts which do not have the Euro symbol]
Hi! Does anyone have any clue what may cause the problem listed below ? Original Message Subject: [Bug 898] New: mkfontscale creates ISO8859-15 lines for fonts which do not have the Euro symbol Date: Sat, 22 Nov 2003 00:53:21 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=898 Summary: mkfontscale creates ISO8859-15 lines for fonts which do not have the Euro symbol Product: Application Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] mkfontscale creates ISO8859-15 lines for fonts which do not have the Euro symbol. Steps to reproduce: 1. Make a new temp. dir: % mkdir test_dir ; cd test_dir 2. get Helvetica.pfa (I'll attach it to this bug in a few secs) % cp /shared/projects/xf86_trunk/fonts/Helvetica.pfa . 3. Run mkfontscale % mkfontscale 4. Show fonts.scale: % cat fonts.scale Result: -- snip -- 5 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-adobe-standard Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso10646-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-15 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-microsoft-cp1252 -- snip -- Expected result: Same as above, excluding the the ISO8859-15 line: -- snip -- 4 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-adobe-standard Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso10646-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-1 Helvetica.pfa -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-microsoft-cp1252 -- snip -- Note that many other PS Type1 fonts have the same problem... ;-(( -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
