| Age | Commit message (Collapse) | Author |
|---|
|
smi_video.c: In function 'SMI_SetupVideo':
smi_video.c:940:24: warning: assignment from incompatible pointer type
pSmi->BlockHandler = pScreen->BlockHandler;
^
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
smi_video.c: In function 'SetAttrSAA7111':
smi_video.c:795:6: warning: declaration of 'i' shadows a parameter [-Wshadow]
int i;
^
smi_video.c:723:39: warning: shadowed declaration is here [-Wshadow]
SetAttrSAA7111(ScrnInfoPtr pScrn, int i, int value)
^
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
I plan to remove the Weak functions from a future server.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
No shadowfb support in this driver yet.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Also don't check for NULL before calling free().
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
src/smi_driver.c: In function ‘SMI_MapMem’:
src/smi_driver.c:1498: warning: format ‘%08lX’ expects type ‘long unsigned int’, but argument 6 has type ‘CARD32’
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
ScrnInfo->pixmapPrivate is gone
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
Fixes a segfault when the destination area is off screen.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Krzysztof Halasa <khc@pm.waw.pl>
|
|
Compiler warning flags should be explicitly set in the makefile
rather than being merged with other packages compiler flags.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
|
On some videos the last displayed line was wrong. This can
be fixed using LynxEM+ VPR68. Code borrowed from siliconmotion's
in-house driver.
Also fix a typo.
Signed-off-by: Cedric Cellier <rixed@happyleptic.org>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
ClockRanges is a silly type and I want rid of it, and the one extra
field it provides that's not in ClockRange, we're not using.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
|
|
|
|
|
|
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers
need to include dpmsconst.h if xextproto 7.1 is available.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
This should allow using a SM502 as secondary display
device (bug 21810).
|
|
Set it to 3MHz so that the pixel clock frequency is overridden
when it's found to be 49MHz, which is reported to be unstable.
|
|
|
|
In some cases the BIOS hasn't filled in the "scratchpad registers"
(SR71) with the right amount of memory installed (e.g. MIPS
platform). There seems to be no other way to do it than to test it.
This should fix bug 21528.
|
|
The default MCLK setting was higher than the clock limit, and it
failed.
|
|
The databook says nothing about it, and it doesn't work.
|
|
Clearing this bit causes an OQO 01+ w/SMI720 to power down the LCD,
leave it alone.
Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Due to checking if SMI501_CLI_DEBUG is defined, some debugging will
be enabled if SMI501_CLI_DEBUG is set to 0. A single #if should be
used instead. Some debugging code already does this.
Signed-off-by: Niels de Vos <niels.devos@wincor-nixdorf.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
|
|
|
|
Probably this makes dualhead mode more useful because it makes
possible displaying video on the LCD as long as the CRT output is
disabled or cloned.
|
|
Also correct only compilation warning about possibly
uninitialized variable.
|
|
FOURCC_YV12 and FOURCC_I420 handling also was buggy. First it was
doing a noop by swapping offset2 and offset3 values twice, and second,
swap is not required when using smi 501/502 CSC video.
Changed SMI_DisplayVideo0501_CSC() to not set static values to
registers in a possible loop, if there is clipping.
|
|
* Program the MCLK to 157MHz on startup.
* Adjust the requested pixel clock if it's near one of the known
stable frequencies.
* Prefer the clock alternative with post scalar turned on when the
denominator is even.
|
|
|
|
After the RandR1.2 implementation the "UseBIOS" option wasn't actually
programming the hardware through VESA BIOS, this brings back that
functionality.
|
|
|
|
|
|
Save some registers not previously tracked, and use pSmi->mode instead
of continuously reading the hardware state.
|
|
|
|
To enable it, set SMI501_CLI_DEBUG to 1 in smi.h, and use
Option "AcellMethod "EXA"
in the Device section of /etc/X11/xorg.conf
This code is enabled mainly for debug purposes. To make if have an
actual performance gain (like when using a sm50x with a "low profile"
"main" processor") it should be required to actually do busy loops
in kernel mode (and hope the costs of context switch will pay it).
In kernel mode it is possible to wait for an interrupt being triggered
when the command list is processed, or when the 2d engine is idle.
This commit should be functional, but, mainly due to debug messages,
should be significantly slower then a build with MI501_CLI_DEBUG
defined to 0.
|
|
This also changes some bit operations to use a "bitfield" equivalent
one, with named fields, that should make it easier to understand what
is being tested.
The enum smi_cli_cmd_code in smi_501.h is code that was added to a
experimental smi_drm.h, but the hardware only supports basic 2d accel,
and to compensate for the extra overhead for maintaining a command
list (assuming it worked correctly) it would be required to have a
special handling, like calling an ioctl to do the "busy loop" in the
kernel (that is, should wait for an irq or a timeout).
The problem is that even if waiting for a idle engine before crafting
a command, and waiting again after submitting the command, there would
be corruption on screen after some time. So, the "busy loop" in the
kernel would only be useful if still using direct writes to mmio
registers.
|
