| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
The kernel framebuffer module uses the hw cursor for the console cursor,
so the driver must ensure it is hidden when setting a video mode.
|
|
The code was inherited from first import of latest smi sources, but
the driver actually programs a mode, so there is no need to check if
there will be a table entry with register contents matching the requested
mode.
|
|
The code is under "<hash>ifdef USE_PANEL_CENTER", as it is buggy, and
regardless of value set to right and bottom, it will crop from 0 to
mode-width/mode-height, and then display a lot of screen artifacts, due
to improper programming. Either way, the CRT in clone mode will display
correctly.
|
|
|
|
The code is <hash>ifdef'ed out by <hash>if SMI_CURSOR_ALPHA_PLANE
because the smi 502 hardware is buggy, but it appears to have worked
for some older hardware revisions (by looking at code available at
ftp.siliconmotion.com.tw).
Keeping it at least for now, as it serves as a simple way to reproduce
the problems described in smi.h.
|
|
Hardware cursor is still disabled in dual head mode due to some problems,
usually when having both panel and crt mapped to the same address, what
appears to confuse the "modes" code.
|
|
Use separate buffers for crt and panel hw cursors.
Describe, and workaround a problem with Dualhead and hw cursor enabled.
It still has the inconvenient of having a blinking X when exiting the server
or switching to a VT; maybe should also save the image currently configured
also (and restore on exit), or just disable hw cursor on dual head mode.
Also revert change to not initialize video on dualhead. Better to have
fully functional video only on panel, that can be resized, then non
resizable video..
|
|
pSmi->IsSecondary was not used, and there should not exist two
instances of the driver managing the same card.
Macro CHECK_SECONDARY() was dependant on a second instance of the driver
for the same card, and also removed.
Some rework should still be done in the cursor code, as it sometimes,
when displaying different data, will leave the hw cursor visible, while
using an argb cursor.
|
|
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.
|
|
It is mean't to be a fallback option, that as long as kernel boots
in framebuffer mode, the X Server should also work.
Correct incorrect value being checked when printing state of Dualhead
option.
The M value when programming PLL3 is actually an 8 bits integer,
so correct it and comments about it.
|
|
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.
|
|
Correct wrong clock calculation for the 501 clock setting, that is used
for pre 502 panel interface and crt.
Adds a few new programmable fields to MSOCRegRec:crt_display_ctl.
Call SMI501_CrtcAdjustFrame() after adjusting a mode, instead of
before changing registers.
|
|
Also print the value of sm502 registers (should be a noop on sm501).
Added the frequency field to the MSOCRegRec's misc_ctl, as it is
a read/write registers, and changing bit 24 may change the logic
of pll3 programming (needs clarification with SMI).
|
|
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?).
|
