Several patches for the siliconmotion driver

[Alex Deucher]

On Mon, Aug 11, 2008 at 3:12 PM, Paulo Cesar Pereira de Andrade
<pcpa at mandriva.com.br> wrote:
> currojerez at gmail.com wrote:
>
>  Hi,
>
>  Do you have any smi contact?
>

I had some smi contacts in the past.

>  (I don't have contacts, just did some help for an OEM...)
>
>  I have a copy of code from siliconmotion for driver versions 2.2.1 and
> 2.2.5
> (xorg version is tagged 1.6.0), and I believe it should be merged/added
> to Xorg
> source tree.

Their tree split from xorg/xf86 quite a while back IIRC.  Lots of
stuff was changed and added to the xorg version (dualhead, exa) since
then.  Their versions and the xorg versions don't have much
significance anymore.  I also broke out the sm501 code into a separate
driver ages ago:
http://cgit.freedesktop.org/~agd5f/xf86-video-smi501/

Alex

>
>  Adding to CC the guys from Mandriva that should have smi contacts, so that
> hopefully the driver can be updated in Xorg, and also with your patches
> integrated.
>
>> Hi
>> I had some issues with a siliconmotion graphics card (sm720 I think, it's integrated in a laptop computer) so I finally decided to look into the driver code... I think I fixed some bugs (and probably I created some new ones too):
>>  - I couldn't get the shadow framebuffer working to rotate the screen: Xorg crashed with a message saying there were no valid modes. This was because the memory size detection was done after the memory mapping in SMI_PreInit so pSmi->FBReserved wasn't initialized and SMI_ValidMode always returned MODE_MEM.
>>  To fix it I moved the memory detection just before the call to SMI_MapMem
>>  BTW, I couldn't use the VideoRam option in the config file to force the memory size, it seems it's looking for that value in pScrn->videoRam, and it is at pScrn->confScreen->device->videoRam
>>  - Switching between VTs didn't worked ( It left a black screen). I was using the vesafb kernel framebuffer driver. I realised it broke at SMI_PreInit, just after the initialization of the vbe submodule . It fails, anyway, so I placed it inside a conditional depending on pSmi->useBIOS (I also had to use that option to make DPMS work).
>>  - When leaving and then entering into the VT, it was unmapping and remapping the framebuffer, but sometimes the aperture address changed and it crashed when switching back to the X VT because the screen pixmap devPrivate wasn't updated with the new address.
>>  To reproduce, start an X server, switch to a text terminal, start a program in that server and then switch back to X.
>>  I fixed it updating pScrn->pixmapPrivate in SMI_EnterVT, and EXADriverPtr->memoryBase too, in case EXA was being used.
>>  - I implemented RandR rotation. It uses basically the old rotation code, but it seems it is not a good idea to use both simultaneously: if you start an X server with the screen rotated by using the driver option, RandR rotation fails because the RandR extension assumes it isn't initially rotated.
>>  There can be a "Rotate" option  in the Monitor section, it's handled by the randr extension but it seems it needs the newer interface 1.2, otherwise I don't think it would make much sense to keep the driver option.
>>  I had to do some modifications on the code to get this working:
>>   * I added the configuration file option "RandRRotation".
>>   * I replaced pSmi->ShadowPitch with pSmi->screenStride, it seems it makes more sense because the lower word of ShadowPitch may change independently.
>>   * I moved the SMI_DEDataFormat to smi_accel.c because it seems it is a piece of code repeated many times in the driver.
>>   * At some places, it is assumed the framebuffer is at FBOffset: when using a shadow framebuffer, FBOffset is the location of the on-screen framebuffer (0 should be used). This made e.g. EXA completly useless with ShadowFB enabled (it crashed).
>>   * In the FBManager initialization, I have replaced xf86InitFBManager with xf86InitFBManagerRegion to reserve some additional space as screen fb: it's unlikely to be the case, but a less efficient alignment in the rotated mode could make the rotated mode need more memory than the unrotated one.
>>     This is not a problem with EXA as the offscreen memory parameters can be easily modified when doing the rotation.
>>   * In SMI_RefreshArea it's assumed that some DE registers are already in some state, this is specially not true when using EXA.
>>   * SMI_ValidMode rejects a mode with different dimensions than the panel. This seems to work now.
>>
>>  - I've messed a little with the EXA uts/dfs code, but I haven't achieved too much... To get it working I had to do some changes:
>>    * The DTS code uses the screen Bpp inestead of the pixmap Bpp... this gives some problems when using pixmaps with different depth to the screen.
>>    * aligned_pitch was computed from src_pitch inestead of the pixmap width.
>>    * When writing the target coordinates to the DE registers, it does y*0xFFFF inestead of y & 0xFFFF.
>>    I also renamed source_pitch to src_pixelpitch as it is very confusing to have src_pitch and source_pitch.
>>    It isn't necessary to call WaitQueue before copying each scanline, but it seems it almost doesn't affect performance.
>>
>>  - Finally, I wanted to have XV with the RandRRotation option enabled.
>>    As it doesn't seem feasible to rotate the video, I did some modifications at SMI_PutImage and SMI_ClipVideo to make PutImage work (incorrectly) with rotation enabled. The image is displayed unrotated. Do you think this is worse than having no XV at all? Maybe it could be useful...
>>
>> I have splitted the patch ( http://delcorp.org/~curro/smi/smi_all.patch ) to make testing easier, but i don't think they are completely independent:
>> http://delcorp.org/~curro/smi/smi_mem.patch
>> http://delcorp.org/~curro/smi/smi_bios.patch
>> http://delcorp.org/~curro/smi/smi_remapmem.patch
>> http://delcorp.org/~curro/smi/smi_randr.patch
>> http://delcorp.org/~curro/smi/smi_exa.patch
>> http://delcorp.org/~curro/smi/smi_randr_xv.patch
>
> Paulo
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>