| Age | Commit message (Collapse) | Author |
|---|
|
|
|
o Define HAVE_XMODES in config.h.
o Correct the LEAVE() macro declaration when SMI_DEBUG is defined.
o Remove prototype for SMI_DGAInit() if HAVE_XMODES is not defined.
o Properly scale value read from sm501 CURRENT_CLOCK register, to
print an appropriate message on startup.
|
|
The LEAVE() macro, when debug is disabled, now is defined as:
<hash>define LEAVE(...) return __VA_ARGS__
This avoids the requirement of a return statement after the LEAVE()
macro call, what can be confusing.
|
|
As described by siliconmotion, it does not work on the smi 502.
Does it work on older revisions? Keeping <hash>ifdef'ed out for now
as it hopefully will be corrected in a newer hardware revision.
|
|
Probably I misunderstood the usage of this register, as it will always
show the same value, regardless of having a crt connected to the "vga"
port or not. Only difference is that while the detect bit is set,
the crt will be blank. This patch should be more of a placeholder for
a possible correction, but it should not cause any side effects, unless
the data field can be zero on a valid situation.
In my test computer, this field, in base 2 is always 1000000010000100,
what doesn't really look like data in rgb 8:8:8...
|
|
Slightly change clock selection code to start using 501 compatible values,
before checking 502 values, if it is a 502.
DPMS for the VGA/second output was being set with bits inverted, that is
dpms-on was programmed as dpms-off and vice versa. This was one of the
reasons of dual head not working.
Corrected wrong vsync programming for the crt. Cut&paste/typo caused
programming vsync with hsync values, and thus, never getting the crt
to accept the mode being programmed.
If adding:
Option "Dualhead" "True"
to xorg.conf, now you should be able to do things like:
$ DISPLAY=:0.0 xrandr --output VGA --right-of LVDS
$ DISPLAY=:0.0 xrandr --output VGA --below LVDS
and so on.
*Iff* there is some way to not have any limitations for video playback,
this option should be made default or automatically configured.
|
|
If Dualhead is set, it will attempt to use setups that allow different
outputs with different contents, instead of crt always cloning panel.
Still not fully functional.
|
|
The "prototype" computer no longer locks, and only "missing feature"
from before the patch is that video and Xaa don't work (only with Exa).
For the moment, just force crt as not connected, and set the proper
registers to make the secondary output clone the panel.
|
|
Moved most of the Lynx-specific code out of the main
functions at smi_driver.c to some new files: smilynx_hw.c
(With CRTC-independent code like global hardware initialization and
mode saving/restoring), smilynx_crtc.c (With the CRTC-local
procedures) and smilynx_output.c (Output power management, DDC and
monitor detection, currently).
Done something similar with the SMI501 code: split
SMI501_ModeInit in three separate functions: SMI501_HWInit that does
the global initialization, and the CRTC mode_set callbacks
SMI501_ModeSet_crt and SMI501_ModeSet_lcd at smi501_crtc.c.
The SMI501_ModeSet code is divided into SMI501_WriteMode_common,
SMI501_WriteMode_lcd and SMI501_WriteMode_crt, each one updates a
different register set in the hardware.
Inside smi_crtc.c, there is mainly hardware independent
code... Initial CRT controller allocation, shadows, rotation and
framebuffer resizing code.
The shadow code currently relies on EXA... I'm not sure what are the
problems of the EXA implementation in MSOC. Does it work?
I think it would be a good thing to get rid of XAA soon: The next
thing I'll be working on will be EXA Composite... I hope it's possible
to get EXA acceleration working at least as fast as the current
XAA. (Although Teddy Wang confirmed me that the SMI720 DMA engine is
broken...)
So, the patch adds some features like new Lynx dualhead modesetting
code, but it probably breaks some other things:
* Video Overlay: I suppose it does work with EXA activated. It seems
it is also possible to have simultaneous overlays in both CRTCs with the
Lynx hardware (I have some code for this, but still work in progress).
* Hardware Cursor (It needs more integration in the CRTC interfaces).
* The old Shadow FB / rotation code, which we should probably drop.
These are in my TODO list... Along with some more cleaning and other
minor issues in the modesetting code.
About the SMI501 RandR1.2 implementation... I suppose it's specially
lacking per-output DPMS (The DPMS field in the System Control register
only affects the CRT, doesn't it?).
|
