[EMAIL PROTECTED] (Niels Möller) writes:
> To get this right, one have to use some kind of frame buffer device
> instead of having the X server bang directly on the hardware. All
> Unices I've heard of have got this for ages, except Linux on PC
> hardware (not sure about the *bsd:s on PC hardware,
Sorry to reply to myself but
On Thu, Oct 26, 2000 at 11:45:59PM -0700, Steve Bowman wrote:
> Oh, another thing on the kbd business - has anyone looked at the
> 3.3.6 kbd open code? That would be a useful thing to do and I have't
> done it. May be faster than patching in your kbd test program
On Thu, Oct 26, 2000 at 06:55:43PM +0200, Marcus Brinkmann wrote:
> On Tue, Oct 24, 2000 at 03:49:40AM -0700, Steve Bowman wrote:
> > Diamond Viper V770 using nv driver.
> >
> > Umm. This driver has at least one really annoying bug. Since this is
> > X-related instead of hurd-related, I'll proba
On Tue, Oct 24, 2000 at 03:49:40AM -0700, Steve Bowman wrote:
> Diamond Viper V770 using nv driver.
>
> Umm. This driver has at least one really annoying bug. Since this is
> X-related instead of hurd-related, I'll probably work it last unless it
> just bugs me too much. Before starting X, I ha
From: [EMAIL PROTECTED] (Niels Mvller)
Date: 25 Oct 2000 19:09:13 +0200
If that is correct, perhaps that should be considered a bug in the
dynamic linker? The Solaris ld.so.1(1) man page says
The default search paths are the runpath recorded in the object,
followed by
On Wed, Oct 25, 2000 at 07:09:13PM +0200, Niels Möller wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > That's a question I can't answer. The last answer I got was that "rpath is
> > the right thing for this problem", and the last comment I got from a Debian
> > developer on this (repre
Niels Möller schrieb:
> To me it makes sense to search any directories in LD_LIBRARY_PATH
> *before* the -rpath directories compiled into the binary.
The last time I looked at the ld.so manpage for exactly this
issue, it said what you say above (and ld.so even behaved in
the documented manner! ;).
Hi
Marcus Brinkmann schrieb:
> 3. xdm deletes LD_LIBRARY_PATH from the environment, which means that
>it can't start other X processes. Setting the following in
>/etc/X11/xdm-config works around that, but might be a security risk(?):
>DisplayManager.exportList: LD_LIBRARY_PATH
>Cou
Robert Bihlmeyer <[EMAIL PROTECTED]> writes:
> I don't quite agree here. I think the kernel should be responsible for
> cleaning up after processes. We don't rely on processes closing all
> their files and freeing all their memory, either. So, even if X
> crashes hard, the console should restore t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> That's a question I can't answer. The last answer I got was that "rpath is
> the right thing for this problem", and the last comment I got from a Debian
> developer on this (representing the majority) was "nothing overrides rpath
> so its evil".
If t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
Hi,
> 1. pflocal gets a load of threads (about 1700 after a couple of minutes
>using X). This doesn't seem to be harmful though. Killing pflocal
>between X sessions help. Does killing pflocal during an X session
> kill X?
Could somebody please
On Tue, Oct 24, 2000 at 01:35:08PM +0200, Robert Bihlmeyer wrote:
> > 1. pflocal gets a load of threads (about 1700 after a couple of minutes
> >using X). This doesn't seem to be harmful though.
>
> I'm seeing something along this lines without X, too. pflocal grows
> without bounds, and takes
Steve Bowman <[EMAIL PROTECTED]> writes:
> Umm. This driver has at least one really annoying bug. Since this is
> X-related instead of hurd-related, [...]
I don't quite agree here. I think the kernel should be responsible for
cleaning up after processes. We don't rely on processes closing all
t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Now it works.
Congratulations!
> 1. pflocal gets a load of threads (about 1700 after a couple of minutes
>using X). This doesn't seem to be harmful though.
I'm seeing something along this lines without X, too. pflocal grows
without bounds, and
On Tue, Oct 24, 2000 at 10:43:20AM +0200, Marcus Brinkmann wrote:
> On Mon, Oct 23, 2000 at 04:35:42PM -0700, Steve Bowman wrote:
> > > On Mon, Oct 23, 2000 at 10:07:34PM +0200, Marcus Brinkmann wrote:
> > > > In fact, it works excellent. XFree86 4.0.1 is just not supporting my
> > > > graphic
> >
On Tue, Oct 24, 2000 at 10:42:44AM +0200, Marcus Brinkmann wrote:
> On Mon, Oct 23, 2000 at 04:31:33PM -0700, Steve Bowman wrote:
> > Today, got it configured. Had a problem with the mouse, patch attached.
> > This causes the mouse to be opened RO instead of RW (-allowMouseOpenFail
> > no longer n
On Mon, Oct 23, 2000 at 04:31:33PM -0700, Steve Bowman wrote:
> Today, got it configured. Had a problem with the mouse, patch attached.
> This causes the mouse to be opened RO instead of RW (-allowMouseOpenFail
> no longer needed).
No, the patch is only good as a quick work around, but should not
> On Mon, Oct 23, 2000 at 10:07:34PM +0200, Marcus Brinkmann wrote:
> > In fact, it works excellent. XFree86 4.0.1 is just not supporting my graphic
> > card, so I can only run 4bit color depth in 800x600 ;) Also, my graphic
> > problems were actually no problems: In depth8, you get only 320x200 (a
Works for me, too!
I downloaded, patched, built, and installed X 4.01 last night. But I
didn't get it configured or running.
Today, got it configured. Had a problem with the mouse, patch attached.
This causes the mouse to be opened RO instead of RW (-allowMouseOpenFail
no longer needed).
There
Hi,
That was easier than I expected. A simple counter increment was missing from
the mouse code, so it didn't receive any events. Now it works.
In fact, it works excellent. XFree86 4.0.1 is just not supporting my graphic
card, so I can only run 4bit color depth in 800x600 ;) Also, my graphic
prob
20 matches
Mail list logo
