One year after Ilja van Sprundel, discovered and reported a large number
of issues in the way the X server code base handles requests from X clients,
they have been fixed.
committed. Removes a #define that wasn't used anywhere (for completeness
and to make the range definitions match what's in the kernel now).
ok jsg@, deraadt@
to permit:
xrandr --output LVDS1 --mode 1280x800 --panning 1380x1024 --scale 1.8x1.8
to behave properly.
based on upstream commit 1bf81af4a6be1113bcc3b940ab264d5c9e0f0c5d that is in
the 1.14 xserver that is not ready for OpenBSD yet
ok matthieu@
all radeon driver variants, except radeonold.
This fixes the conflicting symbols warnings seen by Xorg -configure
and forces it to use radeonold in the generated xorg.conf file.
Xorg -configure is still broken in many ways, and should be
avoided.
hotplug framework.This also takes care of the configuration of the
keyboard layout from the wscons layout that was hacked inside the
keyboard driver.
Tested by many, ok oga@.
This hasn't been used for a very, very, very long time, (since before
OpenBSD had dri support, for example) and it causes segfaults on dri
drivers when sigio is disabled. Now we don't need to do context swaps on sigio
nor are we trying to do interrupts in userland (thank fuck for that) this
function can die the death that I intended it to die about two years ago, may it
burn.
The kernel support the the sigio ioctl will be removed in a couple of
weeks to give people time to update (right now it accepts it, then
ignores it).
ok kettenis@, matthieu@.
attempt to open that first before trying /dev/ttyC[0-7].
This makes X autoconfiguration a tad bit more intuitive on machines
with multiple SBus or UPA framebuffers, where wsdisplay0 isn't the
console. PCI framebuffers are still busted though.
ok matthieu@
The code to add sunffb unconditionally on !solaris for __sparc__
systems is incorrect for openbsd. More specifically, due to interactions
between hardware drivers and wsfb in preinit we can't unconditionally
add wsfb to the list of fallbacks, so we only add wsfb if no other
option was found. Additionally sunffb does not need to be
unconditionally added because the bus probing code will find these
devices already.
So, long story short: make that code chunk conditional on __sparc__ &&
defined(__linux__) instead.
change from !openbsd to __linux__ requested by kettenis@.
Tested by at least myself and stsp@.
ok matthieu@, kettenis@.
- don't list the dead i810 driver anymore
- blacklist the poulsbo chipset which isn't supported by
xf86-video-intel. Gives vesa a chance. ok oga@, kettenis@.
XAA PixmapOps: Sync before accessing unwrapped callbacks.
When using any XAAPixmapOps, we call into unknown but freshly
unwrapped callbacks (like fb ones). Unlike the XAA*Fallback calls,
we did so without syncing first, exposing us to all kinds of
synchronisation issues.
I believe that the rendering errors appeared now because *PaintWindow
vanished (e4d11e58), and we just use miPaintWindow instead. This
takes a less direct route to the hw and ends up at
PolyFillRectPixmap, which very often left drawing artifacts.
We now sync accordingly, and no longer get the rendering artifacts i
was methodically reproducing on radeonhd, radeon, unichrome...
Also, in order to allow driver authors to remove extensive syncing
or flushing to hide this issue, create XAA_VERSION_ defines, put
them in xaa.h and bump the patchlevel.
tested by naddy@ and Edd Barrett. ok oga@.
PCI address space is completely seperate, so we don't have to claim any
resources to avoid clashes with main memory and firmware. Makes accelerated
graphics work on the Tadpole SPARCLE.
ok matthieu@, oga@
CPUs in basic VESA mode:
X86EMU: handle CPUID instruction
Starting X on an AMD Geode LX system such as an Alix board with VGA
connector, the Xorg driver attempts to issue INT 10/0 to go to mode
3 (VGA). The emulator, running the BIOS code, would then spit out:
c000:0282: A2 ILLEGAL EXTENDED X86 OPCODE!
The opcode was 0F A2, or CPUID; it was not implemented in the
emulator. With this patch it handles the CPUID instruction in one of
two ways:
1) if ran on __i386__ or __x86_64__ then it calls the CPUID instruction
directly.
2) if ran elsewhere it returns a canned 486dx4 set of values for function 1.
Tested with & ok matthieu
