This isn't an XF4 specific problem, but I noticed it after upgrading
and getting rid of Xaw3d. I have some Xt code which sets a value like
this:
XtVaSetValues(button, "userData", w, NULL);
and pulls it out later with
XtVaGetValues(kids[i], "userData", &foo, NULL);
Using xaw3d this worked fine,
On Thu, Sep 21, 2000 at 05:23:19PM +0200, Hervé Eychenne wrote:
> I'm in touch with Guillaume Morin <[EMAIL PROTECTED]> in order to package
> one of my application for Debian, called ulog. FYI, it intends to be the
> distributed equivalent of utmp/wtmp for X-window.
Just FYI, the proper name is t
Hope you don't mind if I CC my reply to the Debian X mailing list.
On Thu, Sep 21, 2000 at 12:28:54AM -0700, Terence Ripperda wrote:
> I'm from NVIDIA, working on our 2d/3d drivers. Now that there are XFree86 4.0.1
> packages in development, I'm looking at getting some .deb packages together for
I feel like Bill Murray in _Ground Hog Day_, forced to live the same day
over and over again...
- Forwarded message from Seth Nickell <[EMAIL PROTECTED]> -
From: Seth Nickell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: GLU vs accelerated GL conflicts (XF4.0.1 package problem)
Date
>> Vedran Rodic <[EMAIL PROTECTED]> writes:
> I think that files in subject (located in
> /usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3
> package, since libGLcore.a is clearly mesa specific, I'm not sure
> about libglx.a.
libGLcore.a provides hooks for the X server, that
This isn't an XF4 specific problem, but I noticed it after upgrading
and getting rid of Xaw3d. I have some Xt code which sets a value like
this:
XtVaSetValues(button, "userData", w, NULL);
and pulls it out later with
XtVaGetValues(kids[i], "userData", &foo, NULL);
Using xaw3d this worked fine,
On Thu, 21 Sep 2000, Franklin Belew wrote:
> On Fri, Sep 22, 2000 at 02:19:56AM +0200, Vedran Rodic wrote:
> > Hi!
> >
> > I think that files in subject (located in
> > /usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3 package,
> > since libGLcore.a is clearly mesa specific, I'm no
On Fri, Sep 22, 2000 at 02:19:56AM +0200, Vedran Rodic wrote:
> Hi!
>
> I think that files in subject (located in
> /usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3 package,
> since libGLcore.a is clearly mesa specific, I'm not sure about libglx.a.
>
man dpkg-divert
Frank aka Myt
Hi!
I think that files in subject (located in
/usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3 package,
since libGLcore.a is clearly mesa specific, I'm not sure about libglx.a.
The real reason I'm writing this is that these files in their
current package conflict with NVIDIAs bina
On Thu, Sep 21, 2000 at 01:17:45PM -0500, Brad Hilton wrote:
> Hello,
>
> With the latest version of the phase 2 packages (v8) imlib seems to be
> leaking shared memory segments quite badly. For example, if I start X using
> twm and do ipcs -u I have one segment being used (the proprietary NVIDIA
On Thu, 21 Sep 2000, Franklin Belew wrote:
> On Fri, Sep 22, 2000 at 02:19:56AM +0200, Vedran Rodic wrote:
> > Hi!
> >
> > I think that files in subject (located in
> > /usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3 package,
> > since libGLcore.a is clearly mesa specific, I'm n
On Fri, Sep 22, 2000 at 02:19:56AM +0200, Vedran Rodic wrote:
> Hi!
>
> I think that files in subject (located in
> /usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3 package,
> since libGLcore.a is clearly mesa specific, I'm not sure about libglx.a.
>
man dpkg-divert
Frank aka My
Hi!
I think that files in subject (located in
/usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3 package,
since libGLcore.a is clearly mesa specific, I'm not sure about libglx.a.
The real reason I'm writing this is that these files in their
current package conflict with NVIDIAs bin
On Thu, Sep 21, 2000 at 01:17:45PM -0500, Brad Hilton wrote:
> Hello,
>
> With the latest version of the phase 2 packages (v8) imlib seems to be
> leaking shared memory segments quite badly. For example, if I start X using
> twm and do ipcs -u I have one segment being used (the proprietary NVIDI
Hello,
With the latest version of the phase 2 packages (v8) imlib seems to be
leaking shared memory segments quite badly. For example, if I start X using
twm and do ipcs -u I have one segment being used (the proprietary NVIDIA
driver seems to use that).
However, after starting and stopping imlib
Hello,
With the latest version of the phase 2 packages (v8) imlib seems to be
leaking shared memory segments quite badly. For example, if I start X using
twm and do ipcs -u I have one segment being used (the proprietary NVIDIA
driver seems to use that).
However, after starting and stopping imli
see below.
On Wed, 20 Sep 2000, Brian Paul wrote:
>
>
> Branden Robinson wrote:
> >
> > On Mon, Sep 18, 2000 at 09:54:03AM +0200, Harald Dunkel wrote:
> > > > However, a consensus has formed of late among the XFree86 developers, in
> > > > conjunction with Brian Paul (the mastermind of the Mes
see below.
On Wed, 20 Sep 2000, Brian Paul wrote:
>
>
> Branden Robinson wrote:
> >
> > On Mon, Sep 18, 2000 at 09:54:03AM +0200, Harald Dunkel wrote:
> > > > However, a consensus has formed of late among the XFree86 developers, in
> > > > conjunction with Brian Paul (the mastermind of the Me
18 matches
Mail list logo
