David Dawes dixit:
>Look in os-support/bsd/bsd_mouse.c, specifically the mouseDevs list and
>the FindDevice() function.
Okay, thanks. I will dig into that.
>If you have a /dev/mouse link, check what
>it points too.
There is none in the default installation, so /dev/wsmouse "should" be used.
>O
Hi,
running X without configuration file works, except that the mouse
defaults to a PS/2 mouse, whereas, under MirOS, it's always a wsmouse.
Does anyone have a quick hint where I can patch this, before I go
looking myself? (Yes, I admit I'm too lazy due to the summer heat.)
TIA,
//mirabile
--
I
David Dawes dixit:
>Another useful data point might be a delay loop in place of the usleep().
I was going to try that today, replacing the call usleep in the .s
file with a simple delay loop, but checked first if it still failed
without, and it worked without the usleep workaround.
What did I ch
David Dawes dixit:
>Does replacing the fprintf with sleep(1) make a difference?
Even with usleep(1), glxgears still works. I've committed that
as a temporary workaround now, till we discover the real problem.
//mirabile
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
>
David Dawes dixit:
>Does replacing the fprintf with sleep(1) make a difference?
sleep(1); is enough and even usleep(1000); but it makes a huge
USABILITY difference - while all the printfs were merely disturbing,
I now experience real lag even when just starting up an xterm.
Still 115.200 fps, as
David Dawes dixit:
>Yes, historically I believe that this zopen.c is derived from from the
>older decompress.c.
Keith Packard said something along these lines, too.
I chose to do it myself however, because somewhen between the
1980's and now, OpenBSD might have fixed a thing :) and the
indentatio
David Dawes dixit:
>I still wonder if there is an issue related to libpthread.
Also possible. And we don't have the get*_r() functions (yet).
>Does replacing the fprintf with sleep(1) make a difference?
I will try that ASAP.
See my other mail - removing just the "call" insn from the .s
does ma
This one goes deep into i386 interna...
Dixi:
>Looks like a compiler bug to me.
Okay, it doesn't.
I have generated two assembly files, x1 and x2, to be the
output of the normal compiler command for xc/lib/X11/x11trans.c
with the -S option added.
The difference is that, before compiling x2, I h
Dixi:
>XTRANSDEBUG=2: works
>XTRANSDEBUG=1: does not work
It gets worse.
Compiling with XTRANSDEBUG=1, if I change in xc/lib/xtrans/Xtrans.c
either line 427:
|static XtransConnInfo
|TRANS(Open) (int type, char *address)
|
|{
|char*protocol = NULL, *host = NULL, *port = NULL;
Dixi:
>David Dawes dixit:
>
>>Try editing xc/lib/Xtrans/Xtransint.h and changing the definition of
>>XTRANSDEBUG to 5, rebuilding libX11, and running glxgears against that.
>
>glxgears weirdly enough works now. I'll rebuild without XTRANSDEBUG
>and look if it still works... if so, strange.
Only e
David Dawes dixit:
>Try editing xc/lib/Xtrans/Xtransint.h and changing the definition of
>XTRANSDEBUG to 5, rebuilding libX11, and running glxgears against that.
glxgears weirdly enough works now. I'll rebuild without XTRANSDEBUG
and look if it still works... if so, strange.
>This will enable mo
Sorry if this hits you more than once, but my NNTP posting
to this mailing list seems to be broken today, somehow, as
well as mailing. Trying with MIME instead of uuencode now.
-- Forwarded message --
Newsgroups: gmane.comp.xfree86.devel
Subject: free xc/lib/font/fontfile/decompres
Alan Coopersmith dixit:
> You might want to look at GOK - the GNOME Onscreen Keyboard, which while it
And if GNU GNOME is too bloated, there are other solutions.
I've only tried one, though: xvkbd.
//mirabile
___
Devel mailing list
Devel@XFree86.Org
h
David Dawes dixit:
>Try editing xc/lib/Xtrans/Xtransint.h and changing the definition of
>XTRANSDEBUG to 5, rebuilding libX11, and running glxgears against that.
>This will enable more of the xtrans messages and may help narrow down
>the failure point.
I will do so soonish, got to work for my day
Thorsten Glaser dixit:
>[EMAIL PROTECTED]:/home/tg $ /emul/openbsd/usr/X11R6/bin/xlock -mode gears
>
>
>works. (This uses the old libs from OpenBSD, I think that's
>an XF86 4.4RC2 still.)
Okay, with a more-or-less working C++ (e
David Dawes dixit:
>In OpenBSDLib.tmpl the versions are bumped for releases >= 3.1. Was that
>the ProPolice bump or something else?
Yes, it was.
>>I will try xlock, I think it's got some GLX modes too.
>
>I'm curious because it seems to fail before getting into the GLX-specific
>code.
glxinfo
Alex Deucher dixit:
>> >and two for bsd
>> >
>> >1. bsd monolithic
>> >2. bsd-coremodular as above
>why not just let the kernel provide the drm? Most if not all recent
>linux and bsd kernels (last few years) have drm support. The dri and
>ddx will adapt depending on
David Dawes dixit:
>First of all, thanks for the continued support!
Sure thing, XFree86 has provided us with a stable X implementation
long enough, no reason to fix what ain't broke.
>What is the policy there for bumping shared library majors?
ABI changes.
When they introduced ProPolice, all l
Hi all,
I've built it through, and most of the stuff works for me.
Before updating, you will have to remove /usr/X11R6 in its entirety,
as I've reverted from "cloning OpenBSD behaviour" (in this case, bumping
the shared library majors because of ProPolice) to "principle of least
diffs against the
Dixitur illum [EMAIL PROTECTED] scribere...
>There is a much neater alternative standardized in
>
> ISO/IEC 14755 - Input methods to enter characters from
> the repertoire of ISO/IEC 10646 with a keyboard or other input devices
> http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14755.pdf
I second t
20 matches
Mail list logo
