The death of a disk drive on my old 486 gave me the opportunity to
upgrade the software (Suse 6.1)
to something more contemporary (redhat 7.3). This encouraged yhe upgrade
of XFree86 from 3.3.x
to 4.2.0. In 3.3.x, to run a dual headed system, the color card was
limited to mono or 4 bit, so
activities.
Bringing up a dual headed X from an mda console steps through a console
driver bad pointer when X
terminates (at least it does on Redhat 7.3, 2.4.18-3), leaving stuck
displays. Ctrl-alt-del still works,
but thats about it.
Enjoy
Lee Olsen
[EMAIL PROTECTED]
/*
* Copyright 2003 by Lee Olsen
Hello all;
I'm building 4.4 on one linux redhat 7.3 i686 box and installing on a much
slower i486. Make World and make install on the local i686 box complete
successfully, but make install on the 486 does not. Make install is run
as root
on the 486, which maps to nobody on the nfs mounted build
Marc Aurele La France wrote:
On Mon, 15 Mar 2004, Lee Olsen wrote:
I'm building 4.4 on one linux redhat 7.3 i686 box and installing on a much
slower i486. Make World and make install on the local i686 box complete
successfully, but make install on the 486 does not. Make install
Hello all;
I have an ancient Hercules mono card and monitor that I'd like to use
with 4.4.
As with all ISA cards, it needs exclusive access to it's resources,
which are currently
claimed by various vga objects. Before putting anything in bugzilla, I
thought
listing my proposed changes here
Hello all;
I now have a handle on what is going on and why, and some proposed
chasnges to fix it.
Here's a simplification of the install dependency chain from
xc/lib/font/Makefile:
install:: lib$(LIBNAME).a
lib$(LIBNAME).a : $(SUBDIRS)
$(SUBDIRS) : FRC
@echo making all in
David Dawes wrote:
On Wed, Mar 17, 2004 at 06:55:21PM -0800, Lee Olsen wrote:
Hello all;
I now have a handle on what is going on and why, and some proposed
chasnges to fix it.
Here's a simplification of the install dependency chain from
xc/lib/font/Makefile:
install:: lib
Hello all;
The rendition driver probe routine is freeing usedChips in the wrong place.
It's allocated inside an if xf86GetPciVideoInfo and freed outside the block,
so systems without a pci bus free an uninitialized pointer. Here's a diff of
the proposed chasnge.
Enjoy
Lee
*** rendition.cThu
Hello all;
A couple of things I found while sorting out multihead isa systems:
The vesa driver's probe looks like this:
/* VGA has one more read/write attribute register than EGA */
(void) inb(GenericIOBase + VGA_IN_STAT_1_OFFSET); /* Reset flip-flop */
outb(VGA_ATTR_INDEX, 0x14 |
David Dawes wrote:
On Thu, Mar 18, 2004 at 01:36:13PM -0500, David Dawes wrote:
On a thin client, one without development tools, it's `Cannot find a rule to
build /usr/include/stdio.h' and similar failures during the dependency
checks.
The only way I see to stop these is for `make install'
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.
What makes that hard to do is VBEInit/VBEExtendedInit requires an
entityIndex,
which is not available during configuration. This gets converted
Hello all;
The ati driver is the only one doing dynamic resource determination and
multiple ClaimFixedResources
calls for a single device. Following that model, I put together a
resource gathering scheme to allow
a single AddBusDeviceToConfig call per card. I tried it out with a VGA
Wonder,
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 for the vesa signature
in the bios, and that
means libint10.a and libvbe.a must be able to run without referencing
screens or entities,
Andrew C Aitchison wrote:
On Mon, 29 Mar 2004, Lee Olsen wrote:
The two line vbeModes.c change fixes VBEFindSupportedDepths reporting
zero for depths
les than 15. The symptom I saw is a 512k card requesting a depth of 16,
resulting in No usable
modes.
diff -bc vbeModes.c
Egbert Eich wrote:
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
Egbert Eich wrote:
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
David Dawes wrote:
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 state
Hello all;
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 forward direction of changes that let X440 do
multihead
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 is a tar file of the
hercules driver source
Egbert Eich wrote:
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
. You're either looking at flies or
my binoculars flipped over in the last 12 months.
Enjoy
Lee Olsen
[EMAIL PROTECTED]
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
21 matches
Mail list logo
