On Wed, 14 Jul 2004, Michael Boccara wrote:
> Functions defined in XFree86 are not resolved in libextmod.a when referenced
> as extern.
> Why ?
> Is there a way to help the symbol resolution ?
>
> Thanks,
>
> Michael Boccara
This is a problem you are seeing with the existing code or only
after
On Wed, 14 Jul 2004, Michael Boccara wrote:
> > > Functions defined in XFree86 are not resolved in libextmod.a
> > when referenced
> > > as extern.
> > > Why ?
> > > Is there a way to help the symbol resolution ?
> > >
> >This is a problem you are seeing with the existing code or only
> > afte
DMX unconditionally changed MAXFORMATS in misc.h which modified
the ScreenRec and broke binary compatiblity. No third party drivers
will work with XFree86 after the DMX integration. I think it was
a mistake to unconditionally break binary compatibility in this way.
DMX should be a build option
I'm not enabling DPMS, but DPMS is being used anyhow. This
changed somewhat recently. Was this "on by default" behavior
change intentional?
Mark.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/d
If a software cursor is being used it will be removed before XGetImage
copies that part of the screen. The only way to avoid that is to make
sure a hardware cursor is being used. Nearly all drivers support
the traditional 2 color X11 cursors if it's smaller than a certain
size (usually 32x32 o
This window is using the shape extension? The Xv DDX code
looks at the full rendering cliplist, so it would only cull away
rendering if there were no parts of the window that X could render
to. I don't see any shortcuts in the core code that would be
causing incorrect culling for shaped windo
Don't do the Stop until after you've drawn the non-Xv image.
If the Xv port is an overlay port, drawing the non-Xv image will
replace the Xv image when it overwrites the color key. If the
port is not an overlay port, Stop doesn't do anything.
Mark.
On Mon, 16 Aug 2004,
xc/programs/Xserver/hw/xfree86/xaa/XAA.HOWTO
Mark.
On Thu, 26 Aug 2004, Steven Staton wrote:
> Where is XAA documented? Google is unaware of it, which is a bad omen.
> Does documentation exist?
> ___
> Devel mailing list
> [EMA
It's the app's memory usage that climbs or the server's?
Mark.
On Thu, 14 Oct 2004, [iso-8859-1] Sébastien ZINSIUS wrote:
> Hello!
>
> I'm currently developing a graphical application with Qt/X11 3.1.1. This application
> does a lot of operations and I'm doing some ro
> Is there a way to trace X operations?
There's no tracing feature in Xlib.
Mark.
>
> Cheers,
>
> Sébastien
>
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part
> de Mark Vojkovich
> Envoy
On Fri, 15 Oct 2004, Robert Currey wrote:
> > > Is there a way to trace X operations?
> >
> >There's no tracing feature in Xlib.
> >
> xmon?
That will trace protocol. Not sure if that's useful for
tracking down a client memory leak though. I'm assuming what he
wants to do is watch Xmallo
On Mon, 1 Nov 2004, Bussoletti, John E wrote:
>
> At Boeing we have a number of graphics applications that have been
> developed in-house, originally for various SGI platforms. These
> applications are used for engineering visualization They work well on
> the native hardware and even display we
On Thu, 4 Nov 2004, Barry Scott wrote:
> I need to get rid of the cursor from the Xserver.
>
> There are a number of X client programs on screen and
> I cannot modify all of them to hide the cursor. What I want
> is a way to globally hide the cursor.
>
> Is there a configuration option to get rid
Your app apparently requires OpenGL support. If XFree86 is
your X-server, you need to add:
Load "glx"
to the Section "Module" of the XF86Config file.
Mark.
On Fri, 5 Nov 2004, Simon Toedt wrote:
> Hello,
>
> After adding a print support to our application I am get
All the resources allocated by a single client will have the
same XID prefix. Look at the output of "xwininfo -children -root"
and you'll see what I mean. What you probably want to do is search
from the root and find the all the top-level windows with your
client's prefix.
On Tue, 16 Nov 2004, Dorin Lazar wrote:
> Hello everyone,
> I am trying to obtain a snapshot of the output of an application that draws
> using hardware accelerated Xv. The application is a video player and uses YUV
> format to display and SDL - it draws using SDL_DisplayYUVOverlay function. I
If you want tearless rendering you should be flipping. Ie. render
to a non displayed portion of the framebuffer, then call XDGASetViewport
to display it after the copy is finished. See the DGA test apps at
http://www.xfree86.org/~mvojkovi/, specifically texture.tar.gz.
If the texture and skull
ave no
> control over when the image is actually copied to the display, so tearing
> results, unless someone else here would like to enlighten me...
>
>
>
> On Thu, 25 Nov 2004 11:38:17 -0800 (PST)
> Mark Vojkovich <[EMAIL PROTECTED]> wrote:
>
> >If you want
The nv driver contains no code to program the DVI interface. The
only reason why it works at all with DVI is because the BIOS setup
the timings for the text mode. Subsequently, the nv driver is not
able to run in any mode other than the one the BIOS setup. If the
BIOS setup the text mode to 10
the problems I've been encountering... I'm just not sure it will solve
> all the problems, and will probably add new ones.
>
> Thanks in advance for any input, I'm sure many of you have had to deal
> with similar issues.
>
>
> On Thu, Nov 25, 2004 at 11:38:17AM
On Sat, 27 Nov 2004, James Wright wrote:
>My understanding is that flat panels do not "scan" a screen as a CRT does,
> so there is no vertcial blank period to perform a page flip. They do have a
> refresh rate of usually around 60Hz, but his is simply how aften the pixels
> are able to swit
his I suspect
> is a matroxism though.
>
> Thanks for the replies, this thread has been prettty informative thus
> far.
>
> Cheers.
>
> On Sat, Nov 27, 2004 at 01:56:44PM -0800, Mark Vojkovich wrote:
> >In my opinion, direct framebuffer rendering is passe. My
> >
I synced up and built and now, though the server starts fine,
apps can't get any fonts. Window managers claim they can't find
fontsets like fixed so menus and such have no text in them.
xfontsel seems to work though. Anyone know what's going on?
It's like the fonts.alias isn't being read anymo
On Thu, 20 Jan 2005, Marc Aurele La France wrote:
> On Thu, 20 Jan 2005, Bukie Mabayoje wrote:
> > Mark Vojkovich wrote:
> >>I synced up and built and now, though the server starts fine,
> >> apps can't get any fonts. Window managers claim they can't f
On Sat, 22 Jan 2005, Marc Aurele La France wrote:
> It would seem that you are building with SharedLibFont explicitly set to NO,
> which is the default on a Debian system (see linux.cf). The attached, which
> I've just committed, should fix this problem.
I wonder if Thomas's problems are relat
On Tue, 25 Jan 2005, Marc Aurele La France wrote:
> Mark (and anyone else, of course),
>
> Please tell me whether the attached patch fixes (your version of) the
> problem.
No, it does not.
Mark.
___
Devel mailing list
Devel@
I tried tracing twm when it is drawing fonts. I don't really
understand the font paths very well, but it looks like it never
even draws anything. It looks like:
_XomGetFontSetFromCharSet returns NULL so
_XomConvert returns -1 so
_XomGenericDrawString doesn't draw anything
I walked
On Fri, 28 Jan 2005, Marc Aurele La France wrote:
> On Fri, 28 Jan 2005, Mark Vojkovich wrote:
>
> > I tried tracing twm when it is drawing fonts. I don't really
> > understand the font paths very well, but it looks like it never
> > even d
This is a list about developing XFree86. While some of us might know
a bit about application development, we're probably not the best people
to ask and most of your questions might be met with silence. If you're
looking for X-Window programming resources, Kenton Lee has a site with
a lot of lin
I just updated on my dual-card system and with the update I see
a problem restoring the console that I did not see previously. If
I startx on the primary card and then quit, the primary card is restored
correctly. However, if I startx on both cards and quit, the
primary card is not restored co
ectly. This didn't happen before updating.
MArk.
On Mon, 14 Feb 2005, Mark Vojkovich wrote:
>
>I just updated on my dual-card system and with the update I see
> a problem restoring the console that I did not see previously. If
> I startx on the primary card and
On Mon, 14 Feb 2005, David Dawes wrote:
> On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote:
> > I just updated on my dual-card system and with the update I see
> >a problem restoring the console that I did not see previously. If
> >I startx on the primary ca
On Mon, 14 Feb 2005, Mark Vojkovich wrote:
> On Mon, 14 Feb 2005, David Dawes wrote:
>
> > On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote:
> > > I just updated on my dual-card system and with the update I see
> > >a problem restoring the console
On Mon, 14 Feb 2005, David Dawes wrote:
> On Mon, Feb 14, 2005 at 07:40:40PM -0800, Mark Vojkovich wrote:
> >On Mon, 14 Feb 2005, Mark Vojkovich wrote:
> >
> >> On Mon, 14 Feb 2005, David Dawes wrote:
> >>
> >> > On Mon, Feb 14, 2005 at 04:00:18PM -
On Tue, 15 Feb 2005, David Dawes wrote:
> On Tue, Feb 15, 2005 at 10:34:16AM -0800, Mark Vojkovich wrote:
> >On Mon, 14 Feb 2005, David Dawes wrote:
> >
> >> On Mon, Feb 14, 2005 at 07:40:40PM -0800, Mark Vojkovich wrote:
> >> >On Mon, 14 Feb 2005, Mark Vojkov
It used to be that if you specified a modeline, say "1600x1200" in
the XF86Config file, that modeline would take preference over any
internal modelines of the same name. This no longer appears to be
the case. If I have a "1600x1200" modeline in the XF86Config file,
it no longer gets used, but
On Wed, 16 Feb 2005, David Dawes wrote:
> On Wed, Feb 16, 2005 at 06:07:43PM -0800, Mark Vojkovich wrote:
> > It used to be that if you specified a modeline, say "1600x1200" in
> >the XF86Config file, that modeline would take preference over any
> >internal model
On Thu, 17 Feb 2005, David Dawes wrote:
> On Thu, Feb 17, 2005 at 10:52:33AM -0800, Mark Vojkovich wrote:
> >
> > I think the priority should be: Section "Monitor", EDID, builtin.
> >But it appears that it's EDID, Section "Monitor", builtin.
>
&
On Wed, 2 Mar 2005, Tim Roberts wrote:
> Németh Márton wrote:
>
> > Hi!
> >
> > I've tested 4.5.0RC2 with xtest 4.0.10, see
> > http://bugs.xfree86.org/show_bug.cgi?id=1557 for details.
> >
> > I've attached a test C program which always produces bad rendering
> > using acceleration, and never if
There is no cursor in DGA mode. Clients can still get mouse
events, but that's not the same thing. DGA mouse events reflect
relative motion rather than absolute, and the bulk of the cursor
paths need to be bypassed. That is, the cursor isn't anywhere,
the mouse has been disconnected from the
It's unfortunate that Metacity has that dependency. The .so comes
with newer X-servers. You can try to pull one out of newer X-server
packages. I can mail you the library alone if want.
Mark.
On Wed, 6 Apr 2005, Manikandan Thangavelu wrote:
> Hi All,
>
> I am missi
On Sat, 18 Jun 2005, Michal [iso-8859-2] Maru?ka wrote:
> * Is it correct, that the "nv" driver does not support DBE (double buffer
> extension)?
The drivers have nothing to do with DBE extension support. XFree86
supports DBE for all hardware whenever you load the "extmod" module.
DBE is not
ere was
> discuss about Metacity window, and Manikandan T ask about libXinerama.so.1,
> and you said that you can provide libXinerama.so.1, below was your posting.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Mark Vojkovich
> Sent
] Maru?ka wrote:
> Mark Vojkovich <[EMAIL PROTECTED]> writes:
>
> > On Sat, 18 Jun 2005, Michal [iso-8859-2] Maru??ka wrote:
> >
> >> * Is it correct, that the "nv" driver does not support DBE (double buffer
> >> extension)?
> >
> >T
While i865G hardware might support gamma correction, the
XFree86 drivers for it do not. I believe this is because
nobody with the time or ability to add gamma correction
support the driver have sufficient documentation for the i865.
Mark.
On Wed, 22 Jun 2005, Karthik
X11 is a standard. XFree86 is an implementation of that standard.
Additionally, the X-Window System allows for vendor-specific extensions,
so XFree86 implements features beyond what are covered in the X11 standard.
Mark.
On Sun, 3 Jul 2005, Edison Deng wrote:
> Hi, ev
It probably didn't come with your Linux distribution. It probably
wasn't built by default with the XFree86 version RH9 is using. I've got
one you can use at:
http://www.xfree86.org/~mvojkovi/libXinerama.so.1.0
Stick it in /usr/X11R6/lib and run ldconfig.
Mark.
On Fri, 15 Ju
The NVIDIA Mac boards I've seen are Mac only. They won't even plug
into a PC because the connector is different. It's like PCI, but has
and extra power tab to drive the Apple Display Connector. None of
those boards have a PC BIOS; they have OpenFirmware fcode.
I think most hardware manufa
FPDither takes 8 bit output and dithers down to 6 bit. It
will improve the quality on 6 bit panels and degrade it on 8
bit panels. Nearly all desktop panels are 8 bit (only very cheap
or very old ones are not). Most laptop panels have been 6
bit, but some high-end laptops have 8 bit panels.
On Mon, 3 Oct 2005, Benjamin Herrenschmidt wrote:
> On Sun, 2005-10-02 at 18:32 -0700, Mark Vojkovich wrote:
> >FPDither takes 8 bit output and dithers down to 6 bit. It
> > will improve the quality on 6 bit panels and degrade it on 8
> > bit panels. Nearly all des
Whoops, I'm wrong. It turns out it's not in the EDID. For
desktop systems this is set in the control panel. For laptops,
the driver keeps a list of known panels. The iMac is essentially
a laptop.
Mark.
On Tue, 4 Oct 2005, Benjamin Herrenschmidt wrote:
> >The iMac looks
You can get the server to render to a system memory buffer
using the shadowfb. Many drivers support an Option "ShadowFB"
where rendering happens to system memory and then the driver
periodically flushes the system memory framebuffer to the
real framebuffer. So you may be able to use this syste
It's in the server tree at xc/doc/hardcopy/XProtocol
http://cvsweb.xfree86.org/cvsweb/xc/doc/hardcopy/XProtocol/
Mark.
On Wed, 5 Oct 2005, Eddy Hahn wrote:
> Hi,
>
> I'm in the process to design a system that will traclate wire level protocol
> from X Windows to RDP. So, you an hook up a PC
It's in the server tree at xc/doc/hardcopy/XProtocol
http://cvsweb.xfree86.org/cvsweb/xc/doc/hardcopy/XProtocol/
Mark.
On Wed, 5 Oct 2005, Eddy Hahn wrote:
> Hi,
>
> I'm in the process to design a system that will traclate wire level protocol
> from X Windows to RDP. So, you an hook up a PC
XCopyArea can copy arbitrary rectangles of the desktop if the
source is the root window and the GC has IncludeInferiors for the
sub-window mode.
See the man page on XSetSubwindowMode. There are a few
Xlib functions for getting the root window ID (XRootWindow,
XDefaultRootWindow, XRootWindow
On Wed, 26 Oct 2005, Luke Chen wrote:
> Dear Sir
>
> I hope someone can answer to my following questions,thanks.
>
> I would like to submit our X server display driver to Xfree86.
> I should follow the 4-step program(describes in Xfree86 developer) and simply
> submit my display driver to Bugman?
On Wed, 16 Nov 2005, Alex Deucher wrote:
> On 11/16/05, Smoof . <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I am writing an application that will display up to 9 independent video
> > streams (each stream is 320 x 240). I'm new to Xv and may not be using the
> > correct terminology so please be
On Wed, 16 Nov 2005, Smoof . wrote:
> >On Wed, 16 Nov 2005, Alex Deucher wrote:
> >
> > > On 11/16/05, Smoof . <[EMAIL PROTECTED]> wrote:
> > > > Hello,
> > > >
> > > > I am writing an application that will display up to 9 independent
> >video
> > > > streams (each stream is 320 x 240). I'm new t
The grab is client-specific. The grab will only fail if it's owned
by another client. This is just to prevent multiple apps from fighting
over the same port. It's assumed that if you've got a single client
that client will be able to keep track of which ports it's using.
On Mon, 28 Nov 2005, Tim Roberts wrote:
> Andrew C Aitchison wrote:
>
> >On Mon, 28 Nov 2005, [gb2312] Daniel(???) wrote:
> >
> >
> >
> >>I want to snap a desktop include the mouse pointer. However, the
> >>common tools and functions can not capture a windows image include
> >>mouse. I
I'm not sure what you're asking. "FbBase" and "FbStart" in
most drivers are virtual addresses and not useful to anything
other than the X-server. Do you mean the physical address?
the DGA extension has some protocol to query the physical
address and the start of the framebuffer, but not all
dr
Separate threads either need to use separate display
connections or you need to enable thread mutexes for a shared
connection (XInitThreads will enable Xlib's internal mutexes).
Note still, that pausing a thread while it's in Xlib can block
any other threads also trying to use Xlib with the same
Each call to XOpenDisplay opens a new communication socket to
the X-server. Commands sent through this socket need to be serialized.
If you have two threads trying to send data at the same time through
the same socket they will corrupt each other's data. XInitThreads
enables a lock around the
On Mon, 13 Feb 2006, Barry Scott wrote:
> I have a text scrolling app that is not playing smoothly.
>
> Attempting to update the windows on a timer is not keeping my changes in
> sync with the monitors refresh. This is causing visual glitches.
>
> What mechanisms can I use to lock my changes to th
On Wed, 22 Feb 2006, Barry Scott wrote:
> Mark Vojkovich wrote:
> > The only mechanism I know of is OpenGL. Most OpenGL drivers have
> > a mechanism to allow buffer swapping at vblank.
> >
> Using DRM/DRI this works:
>
> void waitForVSync()
> {
> if( card_
Xkill not only destroys your window, but terminates the client
connection. Your XDisplay is no longer valid from that point
on. The problem you are seeing is that Xlib calls exit() after
calling your IOError handler.
Historically, I believe the only way to continue after the error
handler
I can't get CVS to load NVIDIA's GLX module. It complains:
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
(EE) LoadModule: Module glx does not have a glxModuleData data object.
(II) UnloadModule: "glx"
Did something change with regards to this? It was working before
I updated.
initdata is still NULL even after your call to LoaderSymbol() in
that patch.
Mark.
On Wed, 22 Mar 2006, David Dawes wrote:
> On Wed, Mar 22, 2006 at 06:57:17PM -0800, Mark Vojkovich wrote:
> > I can't get CVS to load NVIDIA's GLX module. It complains:
Yes, that works.
Mark.
On Thu, 23 Mar 2006, David Dawes wrote:
> On Wed, Mar 22, 2006 at 08:52:00PM -0800, Mark Vojkovich wrote:
> > initdata is still NULL even after your call to LoaderSymbol() in
> >that patch.
>
> The module name needs to be prepe
Is that the final fix or is there something else I should test?
That one works for me.
Mark.
On Thu, 23 Mar 2006, Mark Vojkovich wrote:
>
>Yes, that works.
>
> Mark.
>
> On Thu, 23 Mar 2006, David Dawes wrote:
>
> > On Wed, Mar 2
Backing store doesn't really guarantee that you won't get
expose events. I believe the X11 Protocol specification says
that enabling backing store merely tells the server that saving
contents would be "useful" and doesn't guarantee that you won't
get expose events. A program that isn't capable
play - these apps are run over the
> network and the geophysical data is large.
>
> Thanks for your help,
> Paul
>
>
>
> -Original Message-
> From: Mark Vojkovich [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 10, 2006 12:41
> To: Pearson, Paul L-Baker Atlas
fixed the problem. Moving the window around is slower, but
> the drawing is just as fast and the scrolling is reasonable. The boss is
> not happy though.
>
> Is there something I can do to get the acceleration back in?
>
> I had removed all the Load commands from the config file.
On Tue, 6 Jun 2006, Barry Scott wrote:
> I'm seeing the X process take a lot more CPU time to run any workload in
> 1280x768 compared to a standard VGA mode like 1280x1024.
>
> For example running a text scrolling app (lots of XCopyArea calls) I see the
> following CPU usage figures:
>
> 1280x1024
On Wed, 7 Jun 2006, Barry Scott wrote:
> Mark Vojkovich wrote:
> > On Tue, 6 Jun 2006, Barry Scott wrote:
> >
> >
> >> I'm seeing the X process take a lot more CPU time to run any workload in
> >> 1280x768 compared to a standard VGA mode like 128
On Mon, 13 Jan 2003, Tim Roberts wrote:
[...]
> As I recall, there is work going on to eliminate this problem by allowing our
> drivers to claim a whole range of PCI IDs, eliminating the need for
> xf86PciInfo.h. Is that work present in 4.3.0?
>
xf86PciInfo.h isn't needed. I stopped ad
On Mon, 13 Jan 2003, Tim Roberts wrote:
> On Mon, 13 Jan 2003 16:12:21 -0800 (PST), Mark Vojkovich wrote:
>
> >On Mon, 13 Jan 2003, Tim Roberts wrote:
> >
> > [...]
> >
> >> As I recall, there is work going on to eliminate this problem by allowing
> &g
Anyone have any tips on how to debug XFree86 modules under RH8?
It looks like GDB hacked for modules doesn't work on that platform,
or at least the version I have doesn't.
Mark.
___
Devel mailing list
[EMAIL PROTECTED]
h
It's not there anymore.
Mark.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
I don't have any idea. You might want to build a debug server
and break during these pauses to see where it's at.
Mark.
On Fri, 7 Feb 2003, Dominic Duval wrote:
> Hello everyone,
>
> I'm currently trying to speed up X applications and I'm facing huge
> performance
I don't see any problems with that code. There are plenty of
other drivers using it without problems. Perhaps you need to
set the Mono8x8PatternFillFlags. Specifically (from the XAA.HOWTO):
BIT_ORDER_IN_BYTE_MSBFIRST
BIT_ORDER_IN_BYTE_LSBFIRST
As with other color expansion rou
On Sat, 15 Feb 2003, individual wrote:
> Hi.
>
> I haven't been able to find a specification of he layout of image data
> that XCreateImage() expects.
>
The red, green and blue masks within the pixel are in the XImage
structure. The bits_per_pixel (actual size of each pixel) is also
in the
On Sun, 16 Feb 2003, Guido Guenther wrote:
> Hi,
> On Sun, Dec 15, 2002 at 07:47:05PM +0100, Guido Guenther wrote:
> > Tried this but I couldn't get current CVS to crash anymore. But now when
> > switching back from the console the display is all black. When I blindly
> > grab a window and move it
On Sun, 16 Feb 2003, Guido Guenther wrote:
> On Sun, Feb 16, 2003 at 05:28:27PM -0500, Mark Vojkovich wrote:
> [..snip..]
> > - Removal of old fullscreen update code (when VT switching)
> > Does that correspond with the breakage?
> Yeah! Especially the above point l
emove the corruption.
Mark.
On Mon, 17 Feb 2003, Alan Hourihane wrote:
> On Sun, Feb 16, 2003 at 06:57:27 -0500, Mark Vojkovich wrote:
> > On Sun, 16 Feb 2003, Guido Guenther wrote:
> >
> > > On Sun, Feb 16, 2003 at 05:28:27PM -0500, Mark Vojkovich wrote:
Does anyone see any reason why I shouldn't change ShadowFBInit
to pass FALSE? This seems to be produce the original behavior.
Passing TRUE certainly doesn't.
Mark.
On Sun, 16 Feb 2003, Mark Vojkovich wrote:
>
>I don't really know what the
On Wed, 19 Feb 2003, Alan Hourihane wrote:
> Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything
> to add to this, please send it in.
>
> * Mesa 4.0.4 is included for OpenGL(tm) support.
>
> * AMD x86-64 support.
>
> * Support for OpenBSD/sparc64.
>
>
With all the recent errors people have reported about font "fixed",
which turns out to be that xfs wasn't running, maybe there should be
better error reporting in the log file. Is it feasible to report that
the font server isn't running when the unix: font path fails?
If the logfile suggest
On Fri, 21 Feb 2003, Luugi Marsan wrote:
> What does the mioverlay.c do in the mi module of Xfree86? I notice that
It supplements the original mi code. Mi didn't know about anything
other than single layer framebuffers. mioverlay adds a second window
tree and fixes up all window operations
On Fri, 21 Feb 2003, Luugi Marsan wrote:
> So how does the chips driver implement overlay without mioverlay?
>
It's not an overlay in my opinion. Yes, it puts one depth in the
image plane and the other in the overlay plane, but windows in
the overlay clip windows in the image plane and ther
On Fri, 21 Feb 2003, Derek Lukasik wrote:
> > ok... So There's no implementation of overlay using an independent surface on any
> > driver?
>
> Not any open-source driver...
>
> > Also, what is the xf8_32wid? I see that's it's an implementation of the xf8_16bpp
> > but for an 8 over 32 > surfa
I don't see how the window manager could be involved. How
current of CVS? The last thing in the CHANGELOG on my machine is
862 and I don't see this problem.
I think BadMatch can happen with GetImage only if the app
trys to grab outside of the window. I think xmag grabs on the
root wi
The only current implementation that I know of is on IA64.
Maybe Egbert or Marc have been keeping track of this. I'm not
sure how we post secondary cards on IA64 with EFI BIOS cards.
Aside from that issue I don't think it changes the drivers any.
Mark.
On Mon, 24 Fe
mptr) > (int)Intensity(tptr))
> > 905 mptr = tptr;
> > 906 tptr++;
> > 907 }
> > 908 return mptr->pixel;
> > 909 }
> > 910
> > (gdb) p ncolors
> > $1 = 0
> >
> > I pasted some extra lines from the fun
On Wed, 26 Feb 2003, Kendall Bennett wrote:
> Hi Guys,
>
> I am trying to work out if it is possible to 'step outside the box' so to
> speak when writing an XAA driver module for XFree86 4.0. Basically there
> are some functions that we think we can implement faster if we hooked
> them at a hi
window, which is the only type it can grab from. I would guess it
wants the frontmost InputOutput window under the pointer.
Mark.
>
> --
> Kevin
>
>
> Mark Vojkovich wrote:
> >
> >
> >Are there depth 32 windows or something? I
On Thu, 27 Feb 2003, Christoph Pittracher wrote:
> Hello XFree developer team,
> I recently got the new Apple Powerbook G4 12".
> GPU is a Geforce4 440 Go 64M (lspci -vv attached).
>
> I'm running X 4.3 for Debian from http://penguinppc.org/~daniels/. It
> works so far, but the framebuffer (open
On Thu, 27 Feb 2003, Carsten Haitzler wrote:
> On Wed, 26 Feb 2003 20:41:40 -0500 Kevin Brosius <[EMAIL PROTECTED]> babbled:
>
> > The background reports "Depth: 0" with xwininfo. That looks like a
> > problem.
> >
> > The x,y,... to the GetImage seem good, 1103,302,64,64.
>
> naughty xmag. it
On Thu, 27 Feb 2003, Kendall Bennett wrote:
> Keith Packard <[EMAIL PROTECTED]> wrote:
>
> > I think the interfaces currently provided by XAA will probably remain
> > usable, so you might as well implement them.
>
> Ok.
>
> > Plus, we should have XAA expose special higher level functions for
>
I believe there already is. It seems to be letting alot of stuff
through these days, but I expect it's nothing compared to what would
happen if it were turned off.
Mark.
On Thu, 27 Feb 2003, Paul Evans wrote:
> Is there not a spam filter for this kind of th
1 - 100 of 348 matches
Mail list logo
