David Dawes writes:
> On Sun, Jan 12, 2003 at 02:25:35PM -0800, [EMAIL PROTECTED] wrote:
> >Specifically, there are people in Gnome chomping at the bit to help with
> >the xfree86 bug setup and triage problem, with experience at running
> >the Gnome bugzilla system.
>
> >Only time will tell
David Dawes writes:
> On Sun, Jan 12, 2003 at 11:01:01PM +0100, Fernando Herrera wrote:
> >Sun, Jan 12, 2003 at 04:15:15PM -0500, David Dawes escribió:
> >
> >>So it's OK for Linux kernel developers to object to having a bug tracking
> >>system imposed on them but not OK for XFree86 developers
Matt Wilson writes:
> On Sun, Jan 12, 2003 at 07:21:04PM -0500, Georgina Economou wrote:
> >
> > So Matt am I to take it that Redhat is looking to push forward with
> > its Bugzilla and thus get more experience and in the end paid work
> > with it like VA did with Sourceforge? That sounds ver
Matt Wilson writes:
>
> I'm not attempting to bully anyone, nor have I argued that you or any
> other member (individual or corporate) of XFree86. However, there are
> plenty of volunteers that are offering to set up and maintain a bug
> tracking system for you. I think that such a project
David Dawes writes:
>
> It's as simple as me not liking the tools I use during my spare
> time being imposed on me by groups that have more to gain from my
> using them than I do. This big clamour is not coming from the end
> user community, but from groups like gnome, and distros like Red
Keith Packard writes:
> Around 10 o'clock on Jan 13, Egbert Eich wrote:
>
> > To make RandR rotation work one needs layer support. I have a
> > sample implementaion (it takes two lines per driver) however
> > this is too experimental to bee added to 4.3 I'm
Tony Sweeney writes:
> In British English, it's "never buy a pig in a poke", where 'poke' is
> an archaic word for 'bag'. There is another slang phrase, to "let the
OK. thanks for the information!
> cat out of the bag", which is to reveal the truth, for instance that
There is exactly the sam
Vladimir Dergachev writes:
> >
> > The approach I've been thinking about for a while is to replace as much
> > of the .cf data as possible with auto-generated data, and then have
> > imake do it's usual thing. That would give a balance between automatic
> > build configuration and compatibili
Kendall Bennett writes:
> Hi Guys,
>
> We just noticed a strange problem in our driver such that when we do VT
> switching, when switching back to X11 the X server is calling the palette
> programming functions for modes > 8bpp. Any idea why this is? It was
> causing the gamma ramp to get
Mark Cuss writes:
> Hello again all
>
> After some fiddling with the new 4.2.99 X server, I got the xv info stuff
> working on the SMI. But, one more question - the SMI says it can "putImage"
> as well as "putVideo" - does this thing have a built in frame grabber!? I
> couldn't find any sp
Ivan Pascal writes:
> - or move the special action to the compatibility map.
> In the second case we need to introduce some new keysyms (something like
> xf86_Next_VMode, xf86_Prev_Mode, xf86_Ungrab, etc.). But we even don't need
> to add them to the keysymdef.h file but can use the lib/X11/
Michael Cardenas writes:
> Unfortunately, I edited i810_memory.c and changed
>
> if (xf86AgpGARTSupported() && !pI810->directRenderingEnabled
>&& pI810->GttBound) {
>
> to
>
> if (xf86AgpGARTSupported() && pI810->GttBound) {
>
> and it still produces the same error when I laun
Please also add:
* Automatic mouse protocol detection.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Keith Packard writes:
> Around 15 o'clock on Feb 19, "Kurt J. Lidl" wrote:
>
> > You ought to make the xf86jmp_buf larger than 200 bytes.
> > I have access to a machine where the jmp_buf storage takes 232
> > bytes already!
>
> I made it 400 bytes -- Linux x86 uses 156 bytes, and 256 seeme
Dr Andrew C Aitchison writes:
> On Thu, 20 Feb 2003, Egbert Eich wrote:
>
>
> I may not know what I'm talking about.
>
> I thought that the problem was that modules are supposed to work
> across operating system and compiler, so the compile-time size
> mig
If we go into details we should definitely add:
Added BigEndian support to the C&T driver.
Egbert.
Juliusz Chroboczek writes:
> Oh, and what about the Savage changes? XFree86 no longer crashes the
> TwisterK, which is important for a lot of people.
>
> Unless Tim is around, here's my p
Björn Augustsson writes:
> OK, that wasn't so clever...
>
> The rest of the patch is attached... :)
>
> /August.
Hi Bjoern,
I agree with you that this code doesn't have to be replicated
by each driver. There is a lot more code in the video drivers
which could be cept in a centralized place
Mark Vojkovich writes:
> 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.
>
As
Thomas Winischhofer writes:
>
> Just my $0.02: Watch out when centralizing the memory allocation
> routines, different hardware (ie drivers) use different granularities.
>
Yes. Any functions provided by the core server will have the
status of helper functions. Therefore it they don't meet y
Thomas Winischhofer writes:
> Egbert Eich wrote:
>
> Erm, I know that... :) What I actually meant was if Björn starts
> patching *drivers* (and that's what his statements sounded like) he'd
> better take care.
>
OK, sorry, I misunderstood you.
Patching indiv
Martin Spott writes:
> Is it possible for future releases of XFree86 to tag SuSE as using PAM as
> default (in config/cf/linux.cf) ?
>
Unlike other distributions SuSE doesn't have entries in linux.cf.
SuSE uses the host.def you can pick from the source package
of your old version of XFree86.
O
David Dawes writes:
>
> Makefile.kernel was supposed to the a Makefile suitable for dropping
> into the kernel source tree's drivers/char/drm directory. It's never
> used directly from the XFree86 source tree, and that's probably why it
> is out of date. I don't know if there's any point ke
Keith Packard writes:
> Around 0 o'clock on Mar 4, Mark Vojkovich wrote:
>
> > This is the core SW cursor not the ARGB SW cursor, though I haven't tried
> > ARGB SW cursors (I forgot how to set one as the root cursor).
>
> $ XCURSOR_THEME=redglass XCURSOR_SIZE=256 xsetroot -cursor_name shut
Marc Giger writes:
> Hi All!
>
> I want to thank you ALL for the great work. I have a neomagic graphiccard and now
> it is possible to watch movies in fullscreen without interrupts. Also zooming is
> now possible with the Xvideo interface.
Thanks!
>
> As last a short question:
>
> I
jkjellman writes:
> I have been working an input routine that requires a pipe for interactive
> calibration. I need to open the pipe with O_NONBLOCK so as not to halt if a user
> process does not have the pipe open.
>
> In doing this I have found that the xf86open does not support O_NONBLO
Andrew C Aitchison writes:
>
> In xc/programs/Xserver/hw/xfree86/CHANGELOG
> 754. Fixed VBE EDID read: due to a missing register setting read
> ended in endless loop on certain systems (Egbert Eich).
> On a good day an endless loop would be aborted.
You should tell thi
[EMAIL PROTECTED] writes:
> > [EMAIL PROTECTED] writes:
> > >
> > > Of course, there are such advantages to using bugzilla, but the above listed
> > > steps are a lot more overhead for submission of trivial patches than
> > >
> > > cvs diff foo.c | mail -s "Trivial patch to foo
Owen Taylor writes:
> On Wed, 2003-06-04 at 14:59, [EMAIL PROTECTED] wrote:
>
>
> Isn't the number of patches where you don't want:
>
> - An explanation of what is wrong
> - A bug number to be ability to refer to the change later
> - The ability to add further comments to the bug repo
David Dawes writes:
> On Sat, May 17, 2003 at 03:49:46PM -0600, Marc Aurele La France wrote:
> >On Thu, 15 May 2003, Mike A. Harris wrote:
> >
> >> The [EMAIL PROTECTED] mail address still works?
> >
> >Yes.
>
> It works in the sense that email sent to it is accepted and doesn't
> bounce.
Sven Luther writes:
> On Tue, Apr 22, 2003 at 11:58:03AM +0200, Egbert Eich wrote:
> > Sven Luther writes:
> > > Hello, ...
> > >
> > > I have been trying to build the driver SDK thingy on both 4.3.0 and
> > > head, and it seems to be
David Dawes writes:
> On Sat, May 17, 2003 at 01:29:02PM +0200, Sven Luther wrote:
> >On Sat, May 17, 2003 at 07:17:26AM -0400, Mike A. Harris wrote:
> >> On Fri, 16 May 2003, Emmanuel wrote:
> >>
> >> >so finally where it is the best to submit (rather) trivial patches ?
> >> >[EMAIL PROTEC
Dr Andrew C Aitchison writes:
> On 27 May 2003, Scott White wrote:
>
> > Could anyone point me at some instructions to help me compile the
> > XFree86 cvs, I'm having trouble. I want to get access to the via driver
> > recently added to the CVS so I can run X not in vesa mode on my Via
> >
ne and
> > mergedFB options, modes, framebuffer sizes, bit depth (although that
> > might be an issue with some old toolkits), re-run DDC if you connect a
> > new monitor, change OpenGL attributes, tv-out, etc. Obviously this is
> > something for 5.0.
> >
> &
Alex Deucher writes:
> I'm working on integrating my radeon mergedfb code with xfree86 cvs.
> so far it's working, but now I'm trying to integrate the current clone
> code with the mergedfb clone mode. so far so good. I'm trying to use
> the modes defined for the 1st head as clone modes for
Aidan Kehoe writes:
> Ar an 2ú lá de mí 6, scríobh Egbert Eich :
>
> > Also they seem to have difficulties to make attachments
>
> NB; this is not a badly-designed-user-interface issue; bugzilla on
> bugs.xfree86.org is _buggy_ with regard to creating patches.
David Dawes writes:
>
> The submission process is to go to bugs.xfree86.org. If people want
> their submissions to be seen, that's where they should go. That's the
> clearest explanation of the submission system that I can come up with.
>
> Submissions sent elsewhere may or may not be see
Egbert Eich writes:
> Aidan Kehoe writes:
> > Ar an 2ú lá de mí 6, scríobh Egbert Eich :
> >
> > > Also they seem to have difficulties to make attachments
> >
> > NB; this is not a badly-designed-user-interface issue; bugzilla on
> >
David Dawes writes:
> On Tue, Jun 03, 2003 at 10:56:49AM +0200, Egbert Eich wrote:
> >David Dawes writes:
> > >
> > > The submission process is to go to bugs.xfree86.org. If people want
> > > their submissions to be seen, that's where they should go
Emmanuel writes:
> >
>
> So in short : where the "trivial" fixes (more or less like the janitor
> ones) should be submitted (for now they are submitted via bugzilla)?
> Thanks
Yes.
1. Please create yourself a bugzilla account and log in.
2. You can then use the 'create' function to create
Sven Luther writes:
>
> No problem, i have been busy with other things too, and my motherboard
> died on saturday, so i could not do much work this WE.
I'm sorry to hear that.
>
> > > Also, would your new SDK still use a fixed path or should it be possible
> > > to install it anywhere
Frank Baumgart writes:
> Hello Egbert,
>
> > First people advocated that XFree86 has a bugzilla.
> > Now we have one and people complain that it is broken.
> >
> > Our expertise is developing X not running a bugzilla.
> >
> > Where are the people with this expertise, the volunteers
>
Sven Luther writes:
> On Wed, Jun 04, 2003 at 06:02:15PM +0200, Egbert Eich wrote:
> > Sven Luther writes:
> > >
> > > No problem, i have been busy with other things too, and my motherboard
> > > died on saturday, so i could not do much work this WE
Emmanuel writes:
>
> Thanks for the clarity. I have done it as you said already, I will
> insist on the mime type for attachments on the janitor page.
OK, thanks.
> Just one more thing : the patches I have submitted are "trivial" (minor
> mem leaks, clean-ups, and only one more severe bug
[EMAIL PROTECTED] writes:
>
> Of course, there are such advantages to using bugzilla, but the above listed
> steps are a lot more overhead for submission of trivial patches than
>
> cvs diff foo.c | mail -s "Trivial patch to foo" [EMAIL PROTECTED]
>
> For a very short patch like this
Mike A. Harris writes:
> On Wed, 11 Jun 2003, Matthias Scheler wrote:
>
> >> In the interests of portability--their base system doesn't ship with
> >> perl--the NetBSD people have implemented ucs2any.pl in C. There's a version
> >> at
> >>
> >> http://backyard.homeunix.net:8080/~ben/ucs2an
Can you check if the vbe module is loaded (and not unloaded) at this point?
Better yet, post your log file.
Egbert.
Alex Deucher writes:
> I had this problem as well at one point when I was messing with the
> savage driver. What was weird was I hadn't messed with any of the vbe
> stuff. I t
Kirill Semenkov writes:
> Hello,
>
> It is a bug report for savage driver.
> I have problems with Savage video adapter (ProSavage PM133, 8MB RAM) at resolutions
> higher than
> 1024x768 at 24 bpp: any changing in a window (I mean window resizing and moving)
> causes screen g
Thanks!
I will commit this next.
Egbert.
Peter Osterlund writes:
> Hello!
>
> There is a time wraparound bug in the TimerSet function in
> Xserver/os/WaitFor.c. If a timeout handler calls TimerSet to set a new
> timeout which is after the next milliseconds wraparound, the TimerSet
> funct
H. J. Lu writes:
> lndir skips the CVS directory. Shouldn't it also skip BitKeeper? I
> can provide a patch for that.
>
At XFree86 we use cvs, however lndir is a nifty tool that is useful
far beyound X development - in fact everywhere where a version control
system is used.
Please go ahead, y
The version of the module aware gdb on ftp.xfree86.org is
ancient and cannot deal with the debug informations of more
recent versions of gcc.
Is there a newer version around that is accessible thru ftp?
Could we please update the version we have on our ftp server?
Egbert.
___
An interesting question appeared on bugzilla (ID #412).
According to the man page of XListInputDevices() the string
returned in the name field of the XDeviceInfo struct is
supposed to be one listed in XI.h.
In reality it is a name specified by the driver. The same is
true for the type (which accor
Xinput isn't prepared to handle these very device dependent
informations very well.
I have a new xf86misc extension in mind which can be used to
configure device dependent parameters and retreive device dependent
information from devices.
Unfortunately I have been side tracked too much lately that
Owen Taylor writes:
> On Wed, 2003-06-25 at 04:13, Egbert Eich wrote:
> > An interesting question appeared on bugzilla (ID #412).
> >
> > According to the man page of XListInputDevices() the string
> > returned in the name field of the XDeviceInfo struct is
>
"Peter \"Firefly\" Lund" writes:
> On Wed, 25 Jun 2003, Owen Taylor wrote:
>
> > > local->atom = MakeAtom(local->type_name,
> > >strlen(local->name),
>
> strlen(local->type_name) ?
>
Yes, sorry...
Egbert.
__
Dr Andrew C Aitchison writes:
>
> I think we have been into this fight before: the module relies upon OS
> dependent ioctls, so may or may not work at run time, but OS detection is
> at compile-time :-(.
We know the os version:
there are imake defines
OSMajorVersion
OSMinorVersion
OSTeeny
Oliver Wong writes:
> The fix was unsuccessful coming from one person on the Dell forums who
> tried it (I think some others are going to try it though - I posted it
> on the Gentoo forums).
>
It is likely that it is not worrking.
> Thanks for your efforts... if another possible workaround
As I was the one who pointed you to this list I think
I should answer this:
If you woul like to do driver work there is a list of drivers which
are little maintained at the moment.
This list incudes:
i740
i810
rendition
tseng
cirrus (alpine and laguna)
s3 (not s3Virge or savage)
silicon motion
(I
David Dawes writes:
> On Thu, Jun 26, 2003 at 06:46:15PM +0200, Thomas Winischhofer wrote:
> >David Dawes wrote:
> >>
> >> The sis driver goes one better and allows you to tell it which file to
> >> to overwrite :-(
> >
> >This has no real function other than debugging. It's to make it easy
There is a report in bugzilla (#439) which claims:
the bug is in xc/lib/GL/glx/glxcmds.c
int bufSize = XMaxRequestSize(dpy) * 4;
should be
int bufSize = XMaxRequestSize(dpy) * 4 - 8;
or more cleanly
int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq);
it happens that you may comple
Ian Romanick writes:
>
> I looked into the code, and I now understand what's going on. Alexis
> made a good catch of a very subtle bug! The main problem that I had was
> that it wasn't 100% clear at first glance how bufSize / buf / pc were
> used. Some form of "- 8" should be applied to
Dr Andrew C Aitchison writes:
>
> 260. Disabled mode writeback to client program from MGA driver (Egbert
> Eich).
>
> This doesn't compile on RedHat 6.2 / egcs-2.91.66
>
Hi Andrew,
Yes, thanks!
Mattieu already told me.
It builds with gcc 3.3 (however issues wa
Thanks!
I've commited this.
Egbert.
Roland Mainz writes:
>
> Hi!
>
>
>
> Xfree86 source tree, pulled at 2003-06-30 this morning. It seems that
> mkfontscale is generating the encodings.dir files in the wrong order.
> The fontenc code expects the "name filename" order but "mkfonts
Sottek, Matthew J writes:
> The Windows driver does full mode programming including all the external
> digital components from many 3rd party companies. The open source XFree
This is pretty much what the SiS driver does after Thomas got his
hands on it. It programms the SiS and it knows about se
Alexander Pohoyda writes:
> Hi list,
>
> I am unable to find a template to create a rule to install files from
> a directory which does not have a makefile itself.
> I need to process some files matching a mask (e.g. somedir/*.xpm)
> without having to list them all in a makefile.
>
> Ther
Dr Andrew C Aitchison writes:
> On Tue, 1 Jul 2003, Egbert Eich wrote:
>
> I'd be very unhappy to lose the HAL;
> it helps a lot when getting a G550 to work with DVI monitors.
> Some monitors work without it, but others just don't seem to work
> unless I use mg
Dr Andrew C Aitchison writes:
> With Roland's fix, mkfontscale generates encodings.dir files
> containing the string (null), ie with lines like:
>
> big5-0 (null)(null)large/big5.eten-0.enc
> big5.eten-0 (null)large/big5.eten-0.enc
> viscii1.1-1 (null)./viscii1.1-1.enc.gz
> adobe-symbol (nu
David Dawes writes:
>
> Maybe the situation would be better if the mga_hal module was limited
> to doing just those initialisations that can't, for whatever reasons,
> be done in open source. If I recall correctly, the original reason for
> not having this in open source was that enabling th
Juliusz Chroboczek writes:
> >> What sort of checking was done before replaceing mkfontdir with
> >> mkfontscale ?
>
> EE> I had the impression that this had been tested to some extend.
>
> Egbert,
>
> I am sorry if I misled you.
>
No problem. I guess it was my mistake.
So far submi
This is really difficult.
I have compared Julisz's and Kean's patches.
Juliusz doesn't implement the -r option while Kean's code doesn't fix
the '(null)' problem, Kean doesn't generate an encodings file if no
encodings are to be processed while Juliusz generates one containing
a 0.
I could mix both
Kean Johnston writes:
> > Yes, if we don't have an improved version by the end of the week
> > I will revert this.
> I didnt see any comment on my message ... did you see my patch from
> yesterday that implements the -r and -n options?
>
I'm sorry I have overlooked your posting.
I've combin
Kean Johnston writes:
> Egbert Eich wrote:
> > Juliusz, Kean, please check below and tell me if it does what you expect.
> Mostly, except for the -x stuff. Can you and Juliusz apply and try the
> attached patch? This doesnt include the X11.tmpl cleanup portion of my
> orig
Andrew C Aitchison writes:
> On Wed, 2 Jul 2003, Alex Deucher wrote:
>
> > Actually you could probably replace the HAL functionality by using the
> > linux matrox framebuffer driver or directfb driver as a reference. it
> > exposes just about all the functionality of the Gxxx driver (tv out,
Juliusz Chroboczek writes:
> EE> So far submitted code was thoroughly tested...
>
> EE> I would like to get to a situation where the submitter himself
> EE> takes over more responsibilities and takes his code to a committable
> EE> state...
>
> I think that both should be available -- (1
We have a report in Bugzilla (#464), concerning twm. This test can
only be made on NetBSD:
===
if you set /etc/malloc.conf to "AJ" (fill malloc'ed region with random value),
twm crashes occasionary. i'm yet to find out a concrete way to repeat t
Mike A. Harris writes:
> On Thu, 3 Jul 2003, Alex Deucher wrote:
>
> >Date: Thu, 3 Jul 2003 07:10:09 -0700 (PDT)
> >From: Alex Deucher <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Reply-To: [EMAIL PROTECTED]
> >Content-Type: text/plain; charset=us-ascii
> >Subject: Re: S3 Trio64UV+, S3
Roland Mainz writes:
> Hi!
>
>
>
> I filed two bugs+patches to allow users to change the buffer sizes on
> both X11 client + server on demand, see...
> 1. Xserver:
> http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=460 - "RFE:
> Buffer size for the BIGREQUESTS extension sho
Alexander Pohoyda writes:
> I'll try that tonight on the FreeBSD system. We have these options for
> malloc:
>
> A All warnings (except for the warning about unknown flags being
> set) become fatal. The process will call abort(3) in these
> cases.
>
>
Here is an issue for discussion from bugzilla (submitted by Roland
Mainz). Any opinions? Juliusz?
Egbert.
===
RFE: xc/lib/font/FreeType/ font engine should block opening fonts when there is
no encodings file available for it.
Curren
Alexander Pohoyda writes:
> Egbert Eich <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > static int doScalable;
> > static int doBitmaps;
> > -static int doEncodings;
> > +static int onlyEncodings;
> > +static int onlyEncodin
The fix for the SCO OpenServer (Bugz.: 470) contains a piece -see
below - that fixes the VT switching for OS that start numbering
their VTs with 0 instead of 1. This seems to be the case on the
open server but also on SUN i386 (not Solaris 8) platforms.
The code changes also affect these platfo
Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather
current CVS versions. The performance of some tests has gone down by
>20% for a specific test, some other tests have suffered a performance
penalty of >3%.
There may be a simple explanation for this however I can't find it
rig
Juliusz Chroboczek writes:
> I'm currently in the process of changing somewhat the core bitmaps
> fonts system in order to simplify it and extend its functionality.
>
> Because the planned changes will break some users' configurations[1],
> David suggested that the core server should include
This is a matter that maybe should also be discussed on 'forum'.
I don't know how to initiate a joint discussion on both lists.
There is a comment on Roland Mainz's changes to make BIGREQUEST size
tunable.
Further comments are welcome.
Egbert.
=== comment by Juliusz Chroboczek ==
I'd ask this on devel, but I'm certain I won't get an answer
(at least not by anyone but you guys):
Who would be an Xaw expert? Bugzilla #482 describes a situation
(rather unlikely one) where Xaw causes a segfault.
I've tracked it down however I'm not sure what would be the
best solution.
Egbert
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.
Nick Hudson writes:
> On Tuesday 15 July 2003 4:00 pm, Marc Aurele La France wrote:
> [...]
> > The imake rule in question will not be removed because there is nothing
> > to preclude its use by external packages such as those found in X.Org's
> > contrib/.
>
> Ok. Thanks for explaining.
>
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.
Cynthia Grossen has helped me to get a Wiki for XFree86-related
topics started. You can find it under:
http://xfree86.linuxwiki.org
In fact this Wiki has been around for over a year now, but
it has never been announced publically. Since it has been
moved to the linuxwiki.org domain I w
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 t
Christian Zietz writes:
> Hi,
>
> I'm subscribed to the list now, so need to CC anymore.
>
> Egbert Eich schrieb:
> > 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
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 list
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
Alan Coopersmith writes:
>
> This was one of the patches suggested to the X.org IPv6 review which
> we declined to include in our patch set, but which got checked into
> the XFree86 CVS anyway. We were told that separately binding to both is
> the usual habit on OpenBSD, while simply bindin
Yes, I'm sure the posting refers to a Chips&Technologies 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
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
there
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:
> > >
> > > _XSERVTransSocketINETCreateLis
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
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 par
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 e
1 - 100 of 221 matches
Mail list logo
