Age | Commit message (Collapse) | Author |
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
- Added PLL algorithm for a new rev of G200e
- Removed the bandwidth limitation for the new G200e
Fixes : https://bugs.freedesktop.org/show_bug.cgi?id=92540
Change from V1 :
- Make sure we don't cause issue on previous chips. (Dave Airlie review)
Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
- Added support for the new deviceID for G200eW3
- Added PLL algorithm for the G200eW3
- Added some initialization code for G200eW3
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=92541
Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Fixes
passing argument 2 of 'pci_device_cfg_read_u32' from incompatible pointer type
pciaccess.h:153:5: note: expected '__uint32_t *' but argument is of type 'CARD32 *'
Signed-off-by: Thomas Klausner <wiz@NetBSD.org>
Reviewed-by: Connor Behan <connor.behan@gmail.com>
|
|
A driver like this that tries to composite a lot will definitely need to
avoid crashing for solid pictures.
Signed-off-by: Connor Behan <connor.behan@gmail.com>
|
|
This hook was broken and did the same thing as a software fallback.
Signed-off-by: Connor Behan <connor.behan@gmail.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Newer versions of the xserver stricter requirements on header order
which caused the configure tests for EXA support to erroneously fail.
Since XAA was already removed from an earlier version of xserver, the
configure failure meant no acceleration was possible. Patch configure
tests similar to r128.
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
|
|
Dead conditional ever since m12n, must not be needed.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
I mentioned it once, but I think I got away with it all right.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Oh, I had a typo in that patch - so please commit this to fix it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
I've had a Xserver lockup in the mga driver, examining it with gdb showed
this obviously broken loop:
count = INREG(MGAREG_VCOUNT) + 2;
while(INREG(MGAREG_VCOUNT) < count);
It reads the line counter and waits until the counter advances by two. The
cause of the lockup is this - if the kernel reschedules the Xorg process
and lets it run in such a moment when INREG(MGAREG_VCOUNT) returns the
maximum (or maximum minus 1) line count, the loop never exits.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
On my Matrox G550 most videomodes in Xorg didn't work. I found out that it
works if Xorg pixel clock is similar to the pixel clock set on framebuffer
console.
Further analysis showed that the Linux framebuffer driver sets the pan_ctl
register (the register 0xa2) according to the pixel clock, the Xorg driver
doesn't set it.
I copied the code to set the pan_ctl register from the Linux kernel to the
Xorg driver, and most videomodes in Xorg work.
The pan_ctl register is required for both analog and digital output.
The pan_ctl register is saved and restored, this is required so that we
restore text-mode screen or Linux framebuffer correctly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
XAA->USE_XAA add USE_XAA.
Tested-by: Avengence on #xorg-devel
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Previously contained MGA HAL code, was left an empty shell by the
removal of USEMGAHAL in commit 94bbeb132c7eda.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Disable HW cursor by default on G200 server chips as these chips a
re often used with a remote graphics link which cannot display
the HW cursor.
This can be overridden by a config option.
Most desktops today use ARGB cursors anyhow which are not
supported by this driver anyhow. Thus the performance penalty
should be irrelevant.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
|
|
With the previous structure it wasn't immediately clear when SecondCrtc
and HWCursor were set to which value. Make the code more readable.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
|
|
https://launchpad.net/bugs/1180986
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Reviewed-by: Robert Jacobs <robert.n.jacobs@gmail.com>
Tested-by: Robert Jacobs <robert.n.jacobs@gmail.com>
|
|
This patch has been used in Debian, Ubuntu and Gentoo for years.
https://bugs.freedesktop.org/show_bug.cgi?id=18472
https://launchpad.net/bugs/292214
https://bugs.gentoo.org/show_bug.cgi?id=265100
Signed-off-by: Andy MacLean <andy-ub1@themacleans.org.uk>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Robert Jacobs <robert.n.jacobs@gmail.com>
Tested-by: Robert Jacobs <robert.n.jacobs@gmail.com>
|
|
Linear Expansion doesn't work on BE as the bit order in
a word is reversed. ScreenToScreenColorExpansion allows
to adjust the bit order in a byte, still the bytes have
the wrong order.
Reviewed-by: <wharms@bfs.de>
Signed-off-by: Egbert Eich <eich@freedesktop.org>
|
|
Otherwise we might catch devices handled by matroxfb, not the mgag200
kms driver.
Debian bug#697532
Reported-by: olafBuddenhagen@gmx.net
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
|
|
we need to at least setup the memory manager bits so dri1 clients
get a backbuffer. this at least gets gears working again without XAA.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
If we aren't using XAA just add stub storm init/sync functions.
This lets the driver load yay.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Fix mga build after XAA removal.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Only used to store arguments to pass as printf %s strings to xf86DrvMsg
Fixes gcc warnings:
mga_driver.c: In function 'MGAdoDDC':
mga_driver.c:1338:7: warning: assignment discards qualifiers from pointer target type
mga_driver.c:1343:11: warning: assignment discards qualifiers from pointer target type
mga_driver.c:1351:8: warning: assignment discards qualifiers from pointer target type
mga_driver.c:1359:8: warning: assignment discards qualifiers from pointer target type
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
|
|
Silences deprecation warnings from xf86PciInfo.h in current Xorg servers
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
|
|
this should only pick up KMS drivers and not old drm drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
XF86DRI is defined by xorg-server.h, so --disable-dri in the driver
itself does exactly nothing other than not fill in the CFLAGS
and thus stop the driver from compiling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
If it couldn't allocate memory, don't attempt to write a bunch of values
to the NULL pointer before returning it, but just pass the NULL along
right away.
Resolves parfait warnings of the form:
Error: Null pointer dereference (CWE 476)
Write to null pointer 'adapt'
at line 322 of src/mga_video.c in function 'MGASetupImageVideoTexture'.
Function 'MGAAllocAdaptor' may return constant 'NULL' at line 237, called at line 320.
Null pointer introduced at line 237 in function 'MGAAllocAdaptor'.
repeated for every line writing to the adapt pointer in each function.
[ This bug was found by the Parfait 0.4.2 bug checking tool.
For more information see http://labs.oracle.com/projects/parfait/ ]
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
|
|
Expand memory mapping of framebuffer from 8 to 16MB
Fix segfault on redhat distibution
Signed-off-by: Christian Toutant <ctoutant@matrox.com>
|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
This patch produced with:
for f in `git grep -Fwl USEMGAHAL`; do
unifdef -B -UUSEMGAHAL $f | sponge $f
done
Adam Jackson wrote:
Hey, so, remember back in the dark ages when dualhead was this
insanely wild differentiating feature? Matrox thought it was so
special, in fact, that they hid most of the implementation of it
(and a bunch of other stuff) in a binary-only blob called the
HALlib. As you'd expect it was pretty much a cut-and-paste of
the relevant Windows code, and then some open glue to keep it
working; clientlx.c is that glue.
I guess the theory was that if you don't tell people which
registers to duplicate to implement a second pipe in their own
hardware, they won't figure it out? A pretty eyeroll-worthy
idea even at the time, and definitely not something we should be
condoning anymore.
Kill it with fire, but while you're at it, untangle the hideous
mess of MGA_HAL() macros too.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Adam Jackson <ajax@redhat.com>
|
|
Adam Jackson wrote:
Hey, so, remember back in the dark ages when dualhead was this
insanely wild differentiating feature? Matrox thought it was so
special, in fact, that they hid most of the implementation of it
(and a bunch of other stuff) in a binary-only blob called the
HALlib. As you'd expect it was pretty much a cut-and-paste of
the relevant Windows code, and then some open glue to keep it
working; clientlx.c is that glue.
I guess the theory was that if you don't tell people which
registers to duplicate to implement a second pipe in their own
hardware, they won't figure it out? A pretty eyeroll-worthy
idea even at the time, and definitely not something we should be
condoning anymore.
Kill it with fire ...
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|