Lee Olsen writes:
Hello Egbert;
Egbert Eich wrote:
Hello Lee,
thank you for the patches!
Lee Olsen writes:
I have completed my tests with my supply of trailing edge hardware, and
my hercules driver plays
well with X440. There are two attachments, one
David Dawes writes:
My point is that this is just one example of a class of problem
that is not unique to the vesa driver. Therefore solving it within
the vesa driver, while useful, does not solve the underlying problem.
Also, this class of problem is not limited to vintage hardware.
Hello Lee,
thank you for the patches!
Lee Olsen writes:
I have completed my tests with my supply of trailing edge hardware, and
my hercules driver plays
well with X440. There are two attachments, one is a tar file of the
hercules driver source and the other
is unified diffs in the
Lee Olsen writes:
David Dawes wrote:
The Probe() function should not change the hardware state and should be
as non-intrusive as possible. When Probe() reports success, it does
not mean that the driver's PreInit() will succeed. The vesa driver is
not especially unusual in this respect.
David Dawes writes:
Could it be done by simply looking for a string in the BIOS image?
Probably.
In general, relying on the result of Probe() to select the correct
driver is flawed though. There are many cases where Probe() can
succeed but PreInit() will fail. The latest
David Dawes writes:
On Sun, Mar 28, 2004 at 05:14:39PM -0800, Lee Olsen wrote:
Hello all;
The vesa driver probe/FindIsaDevice is doing a vga probe, not a vesa one.
It should be calling a vbe routine to check for a vesa signature.
The Probe() function should not change the hardware
Hi Lee,
Unfortunately your patch is backwards.
Furthermore I'd personally prefer unified over context diffs.
Lee Olsen writes:
Hello all;
The vesa driver's probe only looks for a vga. If you have a real stone
age original vga, you get
No screens found. The vesa probe needs to look
Lee Olsen writes:
Egbert Eich wrote:
You mean you want to map the BIOS memory and search it for the signature.
I believe I want to use int10, function 0x4f, subfunction 0, as is done
in VBEExtendedInit. There may be
other, less intrusive ways.
OK. In this case we should
Matthieu Herrb writes:
Hi,
While working on OpenBSD/amd64 support for XFree86, I found out that the
C preprocessor symbol for AMD64 machines was changed from __x86_64__ to
__AMD64__. But looking at what gcc defines on different AMD63 systems
(*BSD, Linux), it looks __AMD64__ is
Craig Ringer writes:
On Tue, 2004-02-24 at 22:55, Alan Hourihane wrote:
We could leave the option in, but enable it by default, so that this
information is displayed, and allow people to turn it off if it hangs.
Additionally, why not print a log line like
Some versions of this
Christian Zietz writes:
Hi,
as I already pointed out some of the users affected by the problem don't
want to or aren't able to build XFree86 out of the CVS sources.
So I wrote a small hack which wraps around int 0x10 and prevents the
function in question (ax=0x5f64, bx=0x0300) from
Christian Zietz writes:
Hi,
as developer of 855patch I get a lot of feedback from people using
XFree86 on computers with i855GM graphics.
It seems like new notebooks by Dell feature a new video BIOS from Intel
(iirc Build 3066) which finally implements the int 0x10 0x5f11 function
Benjamin Herrenschmidt writes:
Losing the ability of porting code straight from these to the fbdev
drivers will basically kill all my efforts to turn the kernel radeonfb
into a decent driver as I need to be able to re-use the code ATI puts
in the XFree version. I suppose the same will
Sven Luther writes:
Maybe a decision on both parts on this would be ok ? XFree86 could make
sure the licence of the driver code would not conflict with the GPL,
keeping the old one for example, and the fbdev driver authors would
dual-licence the code, both GPL and the old xfree86
Mario Klebsch writes:
Hi!
Am Samstag, 10.01.04 um 13:40 Uhr schrieb Warren Turkal:
Mario Klebsch wrote:
But without digging to deep into that question, does freedesktop only
provide an alternative xlib or do they offer an alternative to XFree
(providing a complete set of
Alexander Stohr writes:
Hello,
i stumbled across the above mentioned define and
related code in the XFree86 sources (lnx_video.c).
comparing X4.1.0 and X4.3.0 i found that the
condtitnal coding of if (base % size) has
vanished at some point in time and the handling
is now
Alan Hourihane writes:
Well, if someone else has a chip, or wants to update and test other
drivers (but be careful with DRI enabled drivers as it needs more work
in the driver). Here's a patch to the neomagic that should work, and
could be used as a template for the other drivers.
Rob Taylor writes:
Has anyone sucessfully run the chips 69030 driver on powerpc
based systems?
I'm trying to get it running on a custon 7410 based board with two 69030's
on,a nd i;'m seing soem off things:
my /proc/pci gives me that:
Bus 0, device 18, function 0:
Rob Taylor writes:
attached is 2 possible outputs of scanpci -v
1st is before running server
2nd is after!
the server hangs waiting for a vertial retrace before reading ddc1, and
needs to be SIGSEGV'd.
the trace from the xserver, verbose 10 is also attached
I had this happen to
Tim Roberts writes:
On Thu, 23 Oct 2003 17:16:19 +0100, Rob Taylor wrote:
Has anyone sucessfully run the chips 69030 driver on powerpc based systems?
I'm trying to get it running on a custon 7410 based board with two 69030's
on,a nd i;'m seing soem off things:
...
Also does anyone
Marc Aurele La France writes:
[EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I
believe, so is Egbert.
No, not currently. I usually go to the web interface and
look at the open bugs, process new ones that can be handled
quickly, or try to assign them to an expert on
Harold L Hunt II writes:
What happens when I assign patches in the Cygwin Xserver project to
[EMAIL PROTECTED]? Does an email go out to everyone with CVS
commit access? Is there a single person that receives this email?
Should I be assigning patches to a specific person to ensure
Harold L Hunt II writes:
So, who wants to handle a high volume of patches specific to Cygwin
after the 4.4.0 branch? Any volunteers? I would appreciate someone
that can commit to a 24 to 48 hour turnaround on committing submitted
patches that don't touch other platforms.
I usually
Richard A. Hecker writes:
I don't know if there is any XFree86 Developer in the LA area.
In fact there may by fewer XFree86 Developer around the world
than you expect. It seems to be a popular misconception that
this project has hundreds of active developers.
Egbert
If you
[EMAIL PROTECTED] writes:
What is the status of the problem of being unable to restore the VGA screen using
the SiliconMotion drivers?
Bugzilla 124 702 have reported the problem. Some comments indicate there is a
working patch, while some comments (and my experience) indicate that
Jim Gettys writes:
Most operating schedulers are much happier to give you the CPU
again if you don't monopolize the CPU, and let the other processes
get the CPU regularly. Generally, they boost the priority
of processes that just use a short amount of CPU, and then
give it back.
Mark Vojkovich writes:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usleep(0) is not good for this because it's jiffy based and usually
never returns in less than 10 msec which has the effect of making
Mark Vojkovich writes:
Your experience is out of date. If I've just filled a Megabyte
DMA fifo and I'm waiting to cram another Megabyte into it, how
quick is my FIFO busy loop then? I've had great success with
sched_yield().
The DMA buffer case may be different than the video
David Dawes writes:
BTW, how are things like host vs target imake binaries handled when
cross-compiling?
Currently in most cases the installed versions are used. Only imake
is compiled as HostProgramTarget(). I don't recall if a target version
is ever built and installed.
This should
Keith Packard writes:
Around 20 o'clock on Sep 20, Ivan Pascal wrote:
The solution is obvious. WaitForSomething should not run any callbacks before
the Select but just check timers and if there are expired timers call select
with a zero timeout. Also the code before the select
Alex Constantine writes:
I would like to participate
Please check out this:
http://www.xfree86.org/developer.html
You can also find some info at
http://xfree86.linuxwiki.org
where I've started adding some development pages.
Egbert.
___
Devel
Rishabh Kumar Goel writes:
Hi!
Thanks for your suggestion. I tried that but nothing worked out.
i am working on NetBSD. So i mapped the memory from 0xA to 0xB. From
this memory mapped I tried to read a single byte from the device and also the
word but of no use. I get only
Bryan W. Headley writes:
Egbert Eich wrote:
Bryan W. Headley writes:
As opposed to writing it to a log file. However keep in mind that what
the X client opts to do with any such message(s) is up to that
installation, including logging it to a file. But I'm thinking more
along
Thomas Winischhofer writes:
So, why is 1024x600 sorted out on this machine then? (I ask because SiS
BIOSes sometimes list wrong modes when probing, and refer to wrong
internal modes numbers. I had hoped that Intel folks just forgot to
change their probe function for this very machine
Bryan W. Headley writes:
Egbert Eich wrote:
Bryan W. Headley writes:
True, and that's a whole other set of problems. At least, in your
example, everything is in the XI layer, if not in the individual driver.
I'm more worried about an XI layer that talks to its drivers
Thomas Winischhofer writes:
It is possible that the BIOS actually knows the mode, but has no VESA
number for it. I have seen this at least on SiS hardware: SiS BIOSes
maintain two mode number lists, one with internal mode numbers, one for
VESA mode numbers. As the i810 BIOS, it has
Alessandro Temil writes:
Hoewever, I am absolutely astonished that the graphics BIOS on a 1400x1050
panel does not know how to set a 1400x1050 mode. That means, for example,
that the kernel console driver could never set a mode that fills the panel.
Does the i810 driver list the
Bryan W. Headley writes:
Egbert Eich wrote:
A lot of error conditions can only be fixed by the administrator.
Can you come up with a really good real life example?
I suppose 'Battery Low' would be one.
That's the easiest one for everyone to grasp. Let's see: problems
Bryan W. Headley writes:
True, and that's a whole other set of problems. At least, in your
example, everything is in the XI layer, if not in the individual driver.
I'm more worried about an XI layer that talks to its drivers, but
there's also a layer in Misc that does the same thing,
Bryan W. Headley writes:
Egbert Eich wrote:
Bryan W. Headley writes:
Egbert Eich wrote:
As you said a HID device is more or less unidirectional. Therefore
you won't be able to detect from the device interface that something
is wrong. The HID interface
Bryan W. Headley writes:
Egbert Eich wrote:
Your definition and mine are very similar. I would continue the
definition to say that even intrinsic server functions, like loading a
driver into memory, can be initiated by a client. Why? Because I would
want to keep the actual server
Bryan W. Headley writes:
Egbert Eich wrote:
As you said a HID device is more or less unidirectional. Therefore
you won't be able to detect from the device interface that something
is wrong. The HID interface itself would have to provide QoS.
Anyway QoS would not be part of XI
Mike A. Harris writes:
Doesn't the following CVS commits implement such an API?
Yes, although I don't like the implementation. It requires that the
client knows the exact details of a particular driver. This should be
replaced by something that provides more information on the
Bryan W. Headley writes:
Maybe not everything... Some things only make sense at server startup,
but yes, I want to make things configurable on the fly - but using
another extension, not XI.
Correct. My outlook is a more generic client -- driver API (remember I
use the word
Bryan W. Headley writes:
Sorry, just telling you how it is, now. hotplug listens to a kernel
message layer, and invokes shell scripts in response to events. These
scripts can load/unload kernel device drivers, mount discs, etc. All
these things would do is write a message to some kind
Bryan W. Headley writes:
David Dawes wrote:
On Fri, Aug 29, 2003 at 02:28:13PM -0400, Joe Krahn wrote:
I've discussed XINPUT before, tried to fix some things, and
realized that the XFree86 XINPUT code needs a complete re-write.
It is particularly messed up for non-pointer devices.
Rafa³ Rzepecki writes:
On Thursday 28 of August 2003 17:59, Egbert Eich wrote:
Sure. What we should probably do now is to get in touch with all
interested parties to get their input. We must make sure we don't
jump too short again.
A generalized API for passing messages to and from
Claus Matthiesen writes:
Actually, I'm really getting into the idea that the device can sort of
tell the application how to interpret its data. I'll elaborate later in
the mail...
OK.
You may want to 'bind' one tablet to one application and the other one
to another appication.
Bryan W. Headley writes:
Egbert Eich wrote:
Claus Matthiesen writes:
Let's just forget about expanding the _XDeviceInfo struct for a minute
and just concentrate on the -type field. Because as regards legacy
software: Does anybody use the -type field? I don't want
Claus Matthiesen writes:
This is a summation of the discussion between the est. Bryan W. Headley,
the est. Egbert Eich and myself so far, along with a few new ideas...
OK. Most people seem to think we need a new way to do device handling of
what is currently called extended devices in X
Claus Matthiesen writes:
Exactly. Sort of guessing on the basis of a string which might contain this
or that isn't good enough for industrial strength software which we all
agree should be able to run under Linux/XFree. But unless I am much
mistaken, there is *no other* way of finding
Claus Matthiesen writes:
Let's just forget about expanding the _XDeviceInfo struct for a minute
and just concentrate on the -type field. Because as regards legacy
software: Does anybody use the -type field? I don't want to change the
-name, that's fine as it is and that's what most
Hi John,
thanks on following up on this.
John Dennis writes:
Anytime in the XServer when MMIO was specified as a mapping flag the
ia64 code would have requested non-cached, this is done for all register
mappings and the VGA framebuffer (because write combining was avoided on
banked
John Dennis writes:
I will confess my understanding is weak when it comes to low level bus
interactions, but I'm learning more eveytime I have to tackle these
issues ;-)
Correct me if I'm wrong, but I thought things like caching and
write-combining are not properties of the PCI
Bryan W. Headley writes:
Egbert Eich wrote:
That is correct. However Claus was talking about the future - once
that is fixed. Appearantly toolkits like gnome already do make use
of the name field.
Sure, albeit dangerously. They had best not be making decisions based on
what's
death writes:
The Savage driver, from which I believe this driver was derived, copies
pScrn- display-virtual[XY] to pScrn-virtual[XY] a page or so above the
call to xf86ValidateModes. Is that not happening here?
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza
Marc Aurele La France writes:
On Tue, 26 Aug 2003, Egbert Eich wrote:
Frankly, I don't see how this EFI MDT can be accurate given that, in
general, whether or not a particular PCI memory assignment will tolerate
caching and/or write-combining is highly device-specific. That would
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have
Committed.
death writes:
Seperate modelines error out on: width too large for virtual size for
everything since this virtual width then is 0. Virtual config does not work,
max/default usable size is used instead.
Reason: via_driver.c:VIAPreInit: xf86ValidateModes is called with
Egbert Eich writes:
David Dawes writes:
Is the static build problem likely to be fixed before Monday's snapshot?
I doubt it. I'm quite overloaded with work. I was going to merge in
the latest patch however I had conflicts applying it. I need to
investigate some more
Dr Andrew C Aitchison writes:
Are you sure you actually want the problem solved anyway ?
We have a laptop with a 125dpi screen and a lecture room projector
with about 8dpi.
If I were to make it run a two screen desktop, and my slide viewer
honoured the true screen DPI, on one screen
Mark McLoughlin writes:
Hi Alan,
My impression was that the purpose of the dummy driver was a skeletal
implementation of a device driver which people could use when writing
new drivers. That's what I used if for anyway :-)
Not really. It is a fully working driver. I wrote it to
David Dawes writes:
On Fri, Aug 22, 2003 at 02:42:55PM +0100, Mark McLoughlin wrote:
Hi Alan,
My impression was that the purpose of the dummy driver was a skeletal
implementation of a device driver which people could use when writing
new drivers. That's what I used if for anyway :-)
Mark Vojkovich writes:
XAA itself doesn't care. You set the LINEAR_FRAMEBUFFER
in the XaaInfoRec Flags if you have a linear framebuffer. If
you don't set that flag it won't put pixmaps in offscreen memory
(because the software rendering code won't be able to deal with
them), and it
Warren Turkal writes:
Is there any chance of upstream acceptance of this type of work? A lot of
the utility binaries should be pretty easy to break out the xc hierarchy.
This issue is coming up from time to time and I have jet failed to
understand the benefit of breaking out things out
Matthew Allum writes:
*but* if you use a libXcursor theme with every cursor icon fully
transparent you can *really* get rid of the cursor, an app changing
the cursors appearance just changes it to another 'invisible' cursor.
I've not seen this 'technique' discussed before.
You
attached patch is an alternative solution for the nolisten handling
of aliases.
It takes the aliases from a list explicitely thus allowing a finer
control than by checking for the equality of the interface specific
functions.
Any opinions?
Egbert.
Index: Xtrans.c
Mark Vojkovich writes:
On Fri, 8 Aug 2003, Egbert Eich wrote:
Mark Vojkovich writes:
Out of curiosity. Is the ipv6 supposed to be working properly now?
Last time I updated, I noticed that remote operation was broken.
That is, Xlib was unable to connect to a remote system
Since this problem comes up quite frequently I have made an article
at:
http://xfree86.linuxwiki.org/AdvancedTopicsFAQ
about how to do this.
Egbert.
Andrew C Aitchison writes:
On Wed, 6 Aug 2003, [gb2312] tom wrote:
I want to hide the cursor when I using touchscreen in XFree86
John Dennis writes:
Now it seems to me that using extra machine instructions (asm version)
or no-op IO is inherently a risky solution to this problem. It would
appear there is some interval of time one must wait for individual VGA
bus transactions complete. The number of extra machine
Mark Vojkovich writes:
NVIDIA root caused this at one point and came to the conclusion
that Linux kernel was incorrectly mapping the memory as cached.
Experiments with setting bit{63} of Base Register fixed the
problem.
OK, this sounds like a very reasonable explanation.
Egbert.
The path below will fix the problem that arises when running
a client on an inet4 only system over tcp with Xlib compiled
with inet6 support.
If noone objects I'll commit it.
Egbert.
Index: Xtranssock.c
===
RCS file:
Marc Aurele La France writes:
You should be able to test for _SC_OPEN_MAX instead of __GNU__.
Oops, yep, that should work, too, of course,
thanks - stupid me.
Presently I check for _POSIX_VERSION = 199309
as POSIX.1 conformant systems require sysconf().
Egbert.
Mathieu Lacage writes:
hi,
I eventually got over my previous AddInputHandler puzzling and kept on
reading code until I finished the included rough outline of useful
code paths in the XServer.
I've extended the article about AddInputHandler() have you read it?
I am planning to
Bugzilla #228 claims that the handling of iso8859-15 in COMPOUND_TEXT
is incorrect. According to the ctext documentation no extended
segments should be used for any approved standard encoding. According
to the newer revision of this doc (xc/doc/specs/CTEXT/ctext.tbl.ms)
is8859-15 is such an
Mathieu Lacage writes:
hi,
I have spent some time recently to dive into XFree86 source code: I am
looking into learning more how it works to understand better X
performance in my application.
One of the things I don't really get is what xf86AddInputHandler is
supposed to be used
Daniel Stone writes:
Yes, but what's the alternate solution? I really don't like the changed-case
solution, as that sets a precedent of sorts. A note should be made somewhere of
the moved files.
One could name it hewlett-packard if lowercase is importand.
KDE moves files around all
There is the following report in bugzilla (#97):
-
On Redhat 8 at any rate, the TRANS_OPEN_MAX constant should be compiled to a
call to sysconf(), but is actually compiled into a default of 256. This breaks
my app, which for various reasons opens 256 file
Matthieu Herrb writes:
I wrote (in a message from Sunday 27)
Keith Packard wrote (in a message from Wednesday 23)
While supporting multiple -nolisten arguments is good, I suggest that the
current '-nolisten tcp' should include both inet4 and inet6 tcp options;
most
Not too many people seem to use xsm together with twm these days.
All relevant changes that in this area took place at or before
Apr,8th 1997. This code came from the SI.
Well, try the patch below.
Whoever added session management support to twm (and forgot to
document it in the man page)
Sven Goethel writes:
sorry for being lazy and not RTFM, but
after i send a patch to the patch email addy,
and i have received an acknowledge ..
- how long does it takes to get an answer - usually
- will it happen to get no answer at all ?
Hm, how long ago did send the email?
I
Marc Aurele La France writes:
On Wed, 23 Jul 2003, Egbert Eich wrote:
Marc Aurele La France writes:
I don't like the peppering of this code with more OS #ifdef's. I think
the approach espoused by Itojun, Todd, Matthieu and Andrew is better.
So maybe you can tell what
This 'nolisten' code was added on 1996/11/24 with revision 3.22.
The cvs log only says:
revision 3.22
date: 1996/11/24 09:58:50; author: dawes; state: Exp; lines: +14 -1
updates
I would assume it was taken straight from a SI merge.
Alan Coopersmith writes:
Maybe I'm missing something,
Hmm,
with the current approach a -nolisten to an alias has no effect
anyway. A '-nolisten tcp' will have the same effect as a
'-nolisten unix': None.
The reason is that a flag is set for the protocol however when
the protocols are initialized the aliases aren't checked.
Also tcp is aliased
Andrew C Aitchison writes:
Egbert's latest patch compiles and runs, but it isn't addressing my problem.
This is with
Red Hat 8.0
Linux 2.4.20-19.8
gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
(I have the same problem with Red Hat 6.2).
The system is *not*
Matthias Scheler writes:
On Tue, Jul 22, 2003 at 09:14:08PM +0200, Egbert Eich wrote:
As I tried to explain binding to an IPv6 socket implicitely binds to
an IPv4 socket.
That's a bug.
According to what I've heared it is intended and
therefore considered a feature.
I'm not going
Fabio Massimo Di Nitto writes:
On Tue, 22 Jul 2003, Matthias Scheler wrote:
On Tue, Jul 22, 2003 at 08:03:35PM +0200, Egbert Eich wrote:
The current CVS code produces the error:
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
Matthias Scheler writes:
I wasn't suggesting to use it on Linux. My suggestion was to revert to
using a single socket on all platforms and use the above code to enable
accepting IPv4 connections on *BSD.
Yes, I understand. I was just looking for a decend way of making
things work on
I've made the patch below which takes care of the problem for me.
I have tried several different versions, I didn't really like any
of them.
This code is one of the rare pieces of code that is rather well
structured and relatively free of any ugly hacks. This fix makes
it a lot uglier, what I
Fabio Massimo Di Nitto writes:
I didn't check/produce any code but the easiest way to implement in linux
is something like (if the user does not specify --nolisten):
bind to ipv6
if it works ok
otherwise fail silently
bind to ipv4
if it works ok
otherwise fail with error
Oops, I haven't rebuilt the server.
Maybe this should be changed to int, 0 and 1.
Egbert.
Dr Andrew C Aitchison writes:
On Wed, 23 Jul 2003, Egbert Eich wrote:
I've made the patch below which takes care of the problem for me.
make[3]: Entering directory `/home/XFree86/4.2/std/xc
Marc Aurele La France writes:
I don't like the peppering of this code with more OS #ifdef's. I think
the approach espoused by Itojun, Todd, Matthieu and Andrew is better.
So maybe you can tell what the big difference is?
It tries to preserve more of the old behavoir with
respect to the
I've accidently sent the wrong file before. Sorry.
Egbert.
Index: Xtrans.c
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtrans.c,v
retrieving revision 3.31
diff -u -r3.31 Xtrans.c
--- Xtrans.c20 Jul 2003 16:12:15 - 3.31
+++
When creating an IPv6 socket on Linux an IPv4 socket seems to be
created also.
The current CVS code produces the error:
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
Fatal server error:
Cannot establish any
Matthias Scheler writes:
This sounds like a bug in Linux's socket implementation. It should allow
an IPv4 and an IPv6 socket to bind to the same port number. This is a
common programming pratice for *BSD or Solaris.
As I tried to explain binding to an IPv6 socket implicitely binds to
Yes, I'm sure the posting refers to a ChipsTechnologies 69030.
This is already supported in 4.3, including video playback.
Capture isn't supported as I never had anything to test it with.
I would have replied to the original email if I had been able to
understand it better.
Egbert.
Tim Roberts
Matthias Scheler writes:
It is necessary in at least NetBSD and OpenBSD because the kernel won't
let you accept IPv4 connection on an IPv6 socket by default. As FreeBSD's
IPv6 is AFAK also KAME based I would expect that it shows the same behaviour.
... while simply binding to IPv6 and
This could easily be integrated in the driver (it would be much more
easy to do than writing a separate program) but like you say in your
disclaimer: we cannot guarantee that nothing bad happens. Therefore
I don't think it is the way to go.
However what I find more interesting is that you updated
We have a bug report at
http://bugs.xfree86.org/show_bug.cgi?id=503
that suggests that when building libraries with callbacks using gcc
the option -fexeptions should be used. It enables C++ programs
to catch the exceptions.
I've talked to a gcc expert and he says that using this option is
sane.
Alan Messer writes:
Tim Roberts wrote:
I've recently been made aware of the XFree86 Savage
driver that VIA released
and is now available on Alan Hourihane's web site.
This driver is so much
superior to the one I've been maintaining that I
should be embarrassed.
My
1 - 100 of 154 matches
Mail list logo
