Thanks, I reassigned this to Florian.

That was an extensive bugreport, thanks.

Just out of curiosity: Why do you use "viafb_accel=0"? Do you have any problems with hardware acceleration or was it just for testing?

What is the native resolution of your device? The stuff concerning "Oqo Model 02" I found indicates it's 800x480, is this correct? If yes you might want to try the additional parameter "viafb_lcd_panel_id=8" which might solve the invisible lines and eventually the high resolution problem.

1. no resolutions higher than 800x600 work
Depends on what your native resolution is. Probably the right viafb_lcd_panel_id is required as I do not really trust the bits of hardware detection that exist. If such an ID (in viafb.txt) does not exist, please report it and I'll add support for it. Other sources of errors might be the downscaling code if you use it.

2. invisible lines
Also depends on the native resolution. We'll see whether it vanishes if the right viafb_lcd_panel_id is supplied. Otherwise I have a few possible sources for this one too.

3. crash on fbset
That's really the hard one. I currently don't have the faintest clue what might cause it. If I can't come up with a better idea I'll inspect what is different when using fbset but this will take a while.

Thanks for help :)
http://www.oqo.com/products/model02/specifications.html
shows that:

display

    * size: 5"
    * native resolution: 800x480
    * zoom: 1000x600 and 1200x720 interpolated modes
    * screen technology: Wide VGA LCD with active digitizer
    * optional Sunlight Optimized display for bright light environments
    * controls: ambient light sensor, adjustable brightness
    * external display support:
          o VGA, HDMI, & DVI monitors up to 1920x1200 resolution
          o DisplaySense™ for detection and recall of external display settings
          o simultaneous dual display in mirrored or extended desktop mode

how to proof that native resolution really is  800x480 ?

With "viafb_lcd_panel_id=8" and "viafb_accel=0" 
the upper part of LCD is visible at the bottom.
For 12x22 font from the bottom:
half of the old line
one old line
one empty line
command prompt (it is seen what is typing);
mc : upper menu (Left, File,..) at the bottom of the screen.

With "viafb_lcd_panel_id=8", "viafb_accel=0" and viafb_mode=1000x600
"soft crash" (dim screen, reboot done by Ctr+Alt+Del)
Fresh test "viafb_lcd_panel_id=8", "viafb_accel=1" and viafb_mode=640x480
-> "soft crash" (with irregular patterns on the screen).

What do you mean saying "Other sources of errors might be the
downscaling code if you use it." Could you give an example of such a downscaling code?

How to find non existent ID in viafb.txt ?

There is a lack of "1920x1200" mode in viafb.txt, I think.
All vista modes work well (in vista). Should they be supported in viafb?

There is no proof necessary, I think we can believe your manufacturer.

I assume you did the first test with "viafb_mode=640x480" or no "viafb_mode"? (which is equivalent)
Was the top also visible on top of the screen and just repeated at the bottom?
So we seem to have also a upscaling bug :(

Can you please test whether everything is fine in native resolution, as in
"viafb_lcd_panel_id=8 viafb_mode=800x480" preferably one time with and one time without "viafb_accel=0"

After having a look at the code I'm not surprised that higher resolutions do not work as this feature is clearly not implemented but an overflow in the upscaling part is just ignored (so what viafb is doing if you supply a higher resolution is just broken upscaling instead of downscaling). Will take this as a feature request for downscaling and ask VIA for the required information (there is some sort of downscaling documented but unfortunately not for the graphic chip you have and there are still around 14-16 parameters that seem to influence scaling but are too poorly documented to use them i.e. "LCD Scaling Parameter 4" <- only information). By "downscaling code" I meant the source code of the driver that is used for downscaling the image the applications draw to the actual screen size. This does not exist which can be seen as error (or it can't be implemented accepting such resolutions would be an error).

We would have a non existent ID if your panel native size would not match one of the IDs there. They are used to scale the framebuffer image to the native resolution of your LCD panel before sending it.

You are right that the mode is missing in the documentation but I can assure you that the driver (at least theoretically) supports it (when no downscaling is required). I'm not sure whether we should list all modes in viafb.txt or if we shouldn't just work for all possible modes.
Yeah we should be at least as good as Windows but that might take a while (getting the needed information, implementing it, testing it, ...)

Yes, with "viafb_mode=640x480" and "viafb_refresh=60".

No, it seems that parts of screen are not duplicated,
just a little rolled (synchronization ?).
Exactly the same effect was up to ~2.6.28 (maybe 2.6.30) in X.
X screen rolled when via_agp loaded and normal when not loaded.
2.6.33, 2.6.34 - it seems to be OK (but another nightmare:
if via_agp loaded sound, usb, net,...do not work).
Maybe in via_agp code is some sort of information for this chip?

With "viafb_mode=800x480" and "viafb_refresh=60" screen is deformoded
exactly the same way like in the case of "viafb_mode=640x480".
However there is no crash when "viafb_accel=1",
but screen is deformed.

There is "800x480" in viafb.txt but maybe parameters for that
mode are inadequate for this extremely small (5" ) LCD?

I will check "1920x1200" :)  , I think today.

For "viafb_mode=640x480" and "viafb_mode=800x480" there is also
large rectangular blinking cursor in the empty line bellow command prompt.
It changes to normal blinking underscore in command line after
setfont or Ctr+Alt+Fn. Also for mc when font 8x16: the bottom help menu
(1 Help 2 Menu ...) is stretched vertically and touch the upper menu
(which is bellow); for 12x22 font there is a space between them.

Remark
When I set "viafb_mode=640x460" (by mistake) it was a crash.
Maybe would be better to add  “force_mode” option  to test unknown modes
and without such an option switch to the default mode?

Linux of course is much better than Windows :)
(eg they do not have "640x480" )

Created attachment 26278 [details]
patch to test if fbset provides strange values

I attached a patch that might give us a hint why fbset produces a crash. It just prints out some values that are used but never checked which I think is the likeliest cause. It would be great if you have the time to test it.
Go to the directory where your viafb-posted lives (.../linux-2.6/) and apply the patch
patch -Np1 -i <patchfile>
(where patchfile is the attachment)[to undo this: you can always restore the old tree via 'git reset --hard']
After that there are 2 alternatives
- the quickest way if no framebuffer is loaded
make M=drivers/video/via modules
insmod drivers/video/via/viafb.ko <module parameters>

- the long way
make modules
make modules_install
<reboot>

With the patch attached fbset should no longer be able to crash (but the mode change won't happen). If you run fbset it will output useful information in your system log that look like this (it will also output one prior to all fbset's ):
>>>viafb_check_var
virtual ...
pixclock = ...
<<<viafb_check_var
Please do 1 or 2 fbset's and post the system log or at least the relevant parts of it. Especially if any of those values were 0 this would explain a crash.


Ah, okay but I can't find any patch to via-agp that seems to be related. Will have a closer look if we don't fix it on the fly. The rotation should neither be a synchronization problem (sync pulses exist for that purpose) nor due to the physical display size.
The screen was correct without the viafb_lcd_panel_id parameter? (the missing lines aside)
Is my understanding correct that hardware acceleration works only if no scaling is used? ("viafb_lcd_panel_id=8 viafb_mode=800x480")

The information request I sent to VIA regarding LCD scaling will probably answered within a week. So maybe there will be patches for better scaling support in 2-3 weeks.

Please note that all test so far were done for kernel rc5.
I was far away from my external monitors    
and I knew only that rc3 (git source) is displaying somewhere,
maybe on CRT.

Today tests with rc3.

1. No matter how is set active device, when viafb starts,
   there is no signal on LCD or Hdmi. After connecting an old
   Phillips 109S  CRT monitor it is seen that viafb displays
   only on CRT.

2. Now, I was able to do fbset commands (using git source).
   In general, fbset does not hang Oqo!!

3. Booting with "800x480-60" and noaccel there are few invisible lines
   (bellow screen). Doing now fbset "640x480-60" all lines becomes visible,
   but there is also a line of the form "        |||||||||" at the upper
   edge of the CRT screen. Also cursor takes form of several blinking points,
   irregularly placed.
   fbset "1280x768-60", "1600x1200-60" succesfull (but these two deformations
   remains).
   fbset "1600x1200-75" -> monitor message "frequency out of range".

4. Botting with "1280x768-60" and accel all is OK - no deformations,
   but no cursor at all.

Previous  successful test with accel (rc5 and LCD) was only
for the native resolution and panel_id=8.

If you can't find appropriate patches to via-agp there is another possibility:
for the latest kernels I must blacklist several modules. Maybe there is some sort of memory overlapping for via-agp and another modules. So, if blacklisted eg. snd-hda-intel there is no screen deformation when only via-agp loaded.
I think that is not so safe to do hard tests with loading these modules - it looks
like I was a small step to damage 1T external hard disk.
However, behavior of viafb is exactly the same in cases when via-agp is loaded or no.

It seems that now most important is to switch display on LCD for rc3?

@no LCD display
Sounds like a bug I and Jon fixed yesterday. Please go to the viafb-posted directory and perform these actions to get the newest driver

git reset --hard
git fetch origin
git checkout origin/viafb-posted

There are actually 3 bugs fixed in there
- init failures of the framebuffer are no longer ignored. This catches malformed (but sadly not yet unknown) mode strings as well as wrong device strings
- 2 sequencing issues, one which has the possibility to start the driver before evaluating the parameters (which is the issue you are experiencing, I think)

Approximately how many mega bytes may take 
git reset --hard
git fetch origin
git checkout origin/viafb-posted
?
(10 mb or 200mb - I do not know which Internet connection chose)

Very few. It just loads the differences between the current version and what you already have. I never measured it but it should be something like 20 patches a 2 KB per patch so maybe it ends up between 50-100 KB. At least that's the magnitude I'd expect.

So I will use home Internet.
Thanks for info
(first part was about 450MB and for that reason this stupid question).

A small problem:
I have done
git clone git://git.lwn.net/linux-2.6.git
cd linux-2.6
git checkout origin/viafb-posted
but there is no directory named "viafb-posted" ???

(Should I do 
git reset --hard
git fetch origin
git checkout origin/viafb-posted
in the directory linux-2.6
or the git-archive was not wright loaded? )

In the directory linux-2.6, sorry that I was a bit lazy before.

Yeah the 'git clone' did fetch a lot of data as it contains about 5 years linux history but gladly linux does not double every week. Perhaps I should have put a little notice on the clone command.

But what about directory named "viafb-posted" ???

So I have (I think)  5 years linux patches :)
I asked this question to not disconnect home Internet
to the end of month :)

OK,
now I haven't seen the first line :)

I have (I hope):

git reset --hard
Checking out files: 100% (32281/32281), done.
HEAD is now at da05ad1 viafb: Don't build in camera-specific code without the camera
localhost linux-2.6 # git fetch origin
remote: Counting objects: 354, done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 260 (delta 222), reused 186 (delta 157)
Receiving objects: 100% (260/260), 69.34 KiB | 28 KiB/s, done.
Resolving deltas: 100% (222/222), completed with 45 local objects.
From git://git.lwn.net/linux-2.6
   2874b1b..d67c009  olpc-2.6.31-cam -> origin/olpc-2.6.31-cam
 + a7835db...2029014 olpc-2.6.34-jc -> origin/olpc-2.6.34-jc  (forced update)
   4da62e6..8bbf50f  viafb-next -> origin/viafb-next
 + da05ad1...381ae24 viafb-posted -> origin/viafb-posted  (forced update)
localhost linux-2.6 # git checkout origin/viafb-posted
Previous HEAD position was da05ad1... viafb: Don't build in camera-specific code without the camera
HEAD is now at 381ae24... Add the viafb video capture driver

As you said less than 1 MB

Just a quick explanation:
The "linux-2.6" directory that was created by the 'git clone' command contains the contents of the viafb-posted branch after the 'git checkout origin/viafb-posted' you did and I therefore called it viafb-posted directory while such a directory does not physically exist (or at least it does not contain what I meant).

Yes that's what I wanted, thanks. Now you should be up-to-date :)

For rc3 and LCD. Refresh=60 and panel=8.
accel=0,1 set during boot.

For modes  “640x480-60” “800x480-60”  fbset OK, but there is rotation.
fbset "720x576-60" -> only four "very high lines", Ctrl+Alt+Fn OK.
fbset “1024x768-60”- white irregular shapes but Ctrl+Alt+Fn OK.

It seems that patch to catch fbset is not needed, for now...

Thank you very much for this explanation.
Could you also say how to see what is hidden in .../linux-2.6/.git/objects/pack?

So we fixed the crash on-the-fly? Well it's good that it's fixed and probably it's not worth to figure out which patch exactly as viafb is currently undergoing too much changes that backporting would be reasonable.

What exactly does "Ctrl+Alt+Fn OK" mean? Does it improve the picture somehow or does it just work?

That are the packed objects of git as described in
http://book.git-scm.com/7_the_packfile.html
What you are asking for is something like an introduction to 'git'. There are a lot of tutorials, 'man git' and http://book.git-scm.com/ that can probably explain it a lot better than I ever could.
Some features are
git log
shows the description of all patches
git log drivers/video/via
shows the description of all patches that touch viafb (or more precisely "drivers/video/via")
git branch -a
shows all branches that are available in your current git tree
git checkout <branch-name|commit-id>
make the files under ../linux-2.6/ identical to the version in the selected branch (branch-name) or just after the commit (commit-id) was applied.
If you still have any questions or are just interested please use the available documentation or just try it.

Yes, you have fixed :)
For last rc3 fbset does not crash Oqo,
but rc5 does.

"Ctrl+Alt+Fn " switch to another text console
OK - I can switch and do something in the new one, at least reboot :)
(just work)

Yes, thank you very much. A moment after I asked this question
I thought "it is in ../.git so man git" an I had seen the author
of the very first remark, uff...  :)

Created attachment 26379 [details]
dmesg

Fatal crash while loading via-agp, ath5k, viafb.

I was trying modprobe -v viafb adding more and more
suspicious modules (ID = 15372).

Blacklisting all these (ID = 15372 )modules modprobe viafb OK.

viafb, via-agp (in that order)  and via-agp, viafb OK

USB=(ehci-hcd, uhci-hcd)

USB, via-agp, viafb   -> viafb OK
via-agp, USB, viafb   -> viafb OK
ath5k, via-agp, viafb -> viafb OK

When via-agp was loaded modules USB and ath5k became unfunctional
despite the order of loading.

However, loading in this order:
via-agp, ath5k, viafb

even viafb is giving up (dmesg attached).

Does viafb itself cause any problems or is it just that it has problems when via-agp is loaded? Or in other words: Does your system work fine if everything including viafb but excluding via-agp is loaded?
I did have a quick look at the via-agp code but I have not found anything suspicious and its duty is too different from what viafb is doing to give me an advantage.
I assume that you meant by "viafb OK" just that it loaded but not that the image is okay (not rolled)? (as you earlier said that Xorg had a similar issue when via-agp is loaded).

I have received an answer from VIA regarding my questions but unfortunately it wasn't too useful. The poorly documented parameters seem to be not related to downscaling but are just fine tuning that which values where determined in measure experiments at VIA. So probably we'll just load the default values (as is done now) and perhaps offer advanced options to play with these values...
Concerning downscaling support and the rolled screen I'm stuck as the only question I seem to get useful answers are of the form "What does 3X5.78 exactly do?" and that's difficult if you don't know the numbers you have to ask for ;) At least I mentioned that I want to know how downscaling on your hardware would work but obviously I got no hint for that one.
In the meantime I had a look at the lcd.c/scaling code and found a lot of work but nothing that looked related to the rotation issue. I have really no idea where it comes, maybe some of the CX700 specific code.

At least the crash on fbset you reported should be fixed in mainline now as Linus merged Jon's branch.

Thanks for information.                                          
It looks (for me, maybe I am not right) that                     
if via-agp is not loaded then everything                         
(excluding agp and drm) works very well.                         
There was many hints on the net:                                 
"blacklist via-agp for Oqo 02"                                   
(I remember that this was reported by Mandus,                    
on oqotalk, ubuntu-forums. These days there are not              
so many this kind of reports, however some can be found still).  
The problem is that it seems that openchrome driver              
is very close to work well with Oqo 02.                          

If via-agp is loaded and other "suspicious" modules are blacklisted
  viafb is working (with rotation of course).                       
If via-agp is loaded eg. USB modules do not work                    
(if via-agp is loaded first and  USB  next there is an error        
in dmesg, similar to this when viafb is loaded without vmalloc,     
and eg. usb-disk cannot be mounted;                                 
if via-agp is blacklisted, USB loaded, external usb-disk            
is mounted very well, then unmounted - for security reasons,        
then via-agp is loaded and when trying to mount again  the          
usb-disk there are another errors connected with I/O).              

However, if modules  are loading in the order described
in last mail, with viafb last, viafb is not working
at all (I have vga console, not rotated, and
errors attached to the last mail).
Probably all other things (except USB, ath5k, viafb - for that order
of loading and maybe 8139too; via-agp is loaded so no
chances to use any of these modules) are working very well
(especially there is no system crash).

With all test so far, viafb was always rotated.

Yes, up to ~2.6.28 X screen looked similar (maybe a few of upper lines
which were at the bottom of X-screen were also deformed - hard to say;
for viafb there is only rotation). Moving pointer to the upper edge
it was on the bottom of the X-screen. These "X-effects" occured both
for vesa and openchrome driver.
For latest kernels there is no this X-screen rotation.
It looks also (>= 2.6.30) that via-agp (alone) is working:
there are no agp or drm errors in Xorg.0.log,
glxgears' FPS is changing from 50 to 190 with via-agp.
(However is working to some extent - for some order of these
modules loading it was: "drm closed" and FPS=500 ....;
for FPS=190 mplayer and vlc give only black screen
for every film).

I had hope that Via answer will solve problems.
Does the "rotation" occur for other computers with CX700 chipset?
I have also looked into lcd.c, I do not know nothing about
this code, but there are some strange parameters in this code,
like offset.

Well I hope that Dave finds the problem in via-agp (in the other bug report you opened) and that it'll make the problem with "via-agp, ath5k, viafb" loading vanish. At least AGP seems to be pretty standardized and is relatively far away from what viafb is doing. Currently viafb is enough work for me and not working 3D is not such a grave problem. Especially since there is no 3D support mainline for all newer VIA IGPs (K8M890, P4M900, VX800, VX855) and the upcoming IGPs (VX900, VN1000) are only supported by VESA drivers at best. So I hope you understand that I have a lot of work (I'm not even paid for) at hand that does not allow me to look into the completely new topic AGP to solve this bug. I understand that you want working 3D as do I but for the time being I concentrate to make viafb as good as possible (without any crashes, without requiring the user to set up a zillion parameters) and if I had time implement nice stuff like support for ShaderModel 4.0 ;)

To be honest I don't know what works. viafb is not very popular (maybe as unpopular as VIA is as graphics vendor). Before it started autoloading about 2 kernel versions ago most people were probably not aware that it even existed. As it does not yet a good job in autodetection I assume that for some it works but is not much different (in default configuration) to not having it or it caused problems, got blacklisted and problems silently ignored...what is really missing for quick development is a big community testing on a wide variety of hardware and reporting bugs (or doing feature requests).
Yeah sorry about the current code, I'm trying to improve it. The problem viafb has is that it ended up in the kernel only about 2 years ago and then was mostly untouched for about a year until I took it over, integrated Haralds patches and wrote my own. That's a much shorter period of time then the 5 years unichrome (and later openchrome) had to clean up the code and evolve. But on some topics we are already better than them, for example dual-fb (~dual-head) and 30bpp support so I think we're doing a good job.

Let me summarize it again:
The "rotation" does only happen on LCD (not on CRT/DVI) and only if "viafb_lcd_panel_id=8" is specified (otherwise some lines at the bottom are outside the screen)?

Your summarization of "rotation" is correct.
(But lines outside the screen appear also for DVI and CRT)

======================================

I didn't know that viafb code was mostly untouched
by last 2 years, but I am using it from 2.6.28
(I were'nt so brave :) to do many experiments with it before).

Viafb is very brave to work together with via-agp
( not always however, as shows attached dmesg).

From via-agp point of view the use of agp probably is not the most important
problem (however impossibility  to load viafb for some circumstances
is not very nice - but, it looks that the problem is in via-agp
not in viafb code). From the point of view of Oqo user it is horrible:
if via-agp is loaded USB, ath5k, ... are copletely out of order
(and openchrome driver probably has now accel ability,
especially for hdmi connection).

There must be a misunderstand - I did not ask you to do something.
I just gave information and I didn't assume that
all that information is important for you.
Please, simply skip unimportant parts of that information.

The community of Oqo users probably is not very large
(Oqo is out of stock now). Two years ago many people were trying
Ubuntu, Debian, Fedora, Gentoo on Oqo's computers.
They are now probably testing Linux on newer so slow pocket computers
that even cannot have hdmi slot.

Hi,

there is a chance that I found out what caused the rotation. Can you please test the viafb-s3v1 branch of git://github.com/schandinat/linux-2.6.git
But it is until now only ecpected to work for non-scaled/non-centered mode (that means only when the resolution is set to 800x480)
You can reuse the git tree of last time (if you didn't delete it in the meantime) by doing the following in the linux-2.6 directory

git remote add viafb git://github.com/schandinat/linux-2.6.git
git fetch viafb
git checkout viafb/viafb-s3v1

(I think this is one kernel version later than we used last time so I'd guess this might transfer 1-5 MB)

For further information:
http://www.kernel.org/pub/software/scm/git/docs/git-remote.html

Thanks for nice information.
I'll find last git tree till evening.

On Sun, Sep 19, 2010 at 11:21 PM, <bugzilla-daemon@bugzilla.kernel.org>wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=15904
>
>
>
>
>
> --- Comment #27 from Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
>  2010-09-19 21:21:43 ---
> Hi,
>
> there is a chance that I found out what caused the rotation. Can you please
> test the viafb-s3v1 branch of git://github.com/schandinat/linux-2.6.git
> But it is until now only ecpected to work for non-scaled/non-centered mode
> (that means only when the resolution is set to 800x480)
> You can reuse the git tree of last time (if you didn't delete it in the
> meantime) by doing the following in the linux-2.6 directory
>
> git remote add viafb git://github.com/schandinat/linux-2.6.git
> git fetch viafb
> git checkout viafb/viafb-s3v1
>
> (I think this is one kernel version later than we used last time so I'd
> guess
> this might transfer 1-5 MB)
>
> For further information:
> http://www.kernel.org/pub/software/scm/git/docs/git-remote.html
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

I have :) , I think.

git remote add viafb git://github.com/schandinat/linux-2.6.git
localhost linux-2.6 # git fetch viafb
remote: Counting objects: 110950, done.
remote: Compressing objects: 100% (15562/15562), done.
remote: Total 88440 (delta 73089), reused 86748 (delta 71690)
Receiving objects: 100% (88440/88440), 26.69 MiB | 600 KiB/s, done.
Resolving deltas: 100% (73089/73089), completed with 8142 local objects.
From git://github.com/schandinat/linux-2.6
 * [new branch]      2.6.36-fixes -> viafb/2.6.36-fixes
 * [new branch]      master     -> viafb/master
 * [new branch]      viafb-next -> viafb/viafb-next
 * [new branch]      viafb-s2v1 -> viafb/viafb-s2v1
 * [new branch]      viafb-s3v1 -> viafb/viafb-s3v1
 * [new tag]         v2.6.25    -> v2.6.25
 * [new tag]         v2.6.25-rc8 -> v2.6.25-rc8
 * [new tag]         v2.6.25-rc9 -> v2.6.25-rc9
 * [new tag]         v2.6.26    -> v2.6.26
 * [new tag]         v2.6.26-rc1 -> v2.6.26-rc1
 * [new tag]         v2.6.26-rc2 -> v2.6.26-rc2
 * [new tag]         v2.6.26-rc3 -> v2.6.26-rc3
 * [new tag]         v2.6.26-rc4 -> v2.6.26-rc4
 * [new tag]         v2.6.26-rc5 -> v2.6.26-rc5
 * [new tag]         v2.6.26-rc6 -> v2.6.26-rc6
 * [new tag]         v2.6.26-rc7 -> v2.6.26-rc7
 * [new tag]         v2.6.26-rc8 -> v2.6.26-rc8
 * [new tag]         v2.6.26-rc9 -> v2.6.26-rc9
 * [new tag]         v2.6.27    -> v2.6.27
 * [new tag]         v2.6.27-rc1 -> v2.6.27-rc1
 * [new tag]         v2.6.27-rc2 -> v2.6.27-rc2
 * [new tag]         v2.6.27-rc3 -> v2.6.27-rc3
 * [new tag]         v2.6.27-rc4 -> v2.6.27-rc4
 * [new tag]         v2.6.27-rc5 -> v2.6.27-rc5
 * [new tag]         v2.6.27-rc6 -> v2.6.27-rc6
 * [new tag]         v2.6.27-rc7 -> v2.6.27-rc7
 * [new tag]         v2.6.27-rc8 -> v2.6.27-rc8
 * [new tag]         v2.6.27-rc9 -> v2.6.27-rc9
 * [new tag]         v2.6.28    -> v2.6.28
 * [new tag]         v2.6.28-rc1 -> v2.6.28-rc1
 * [new tag]         v2.6.28-rc2 -> v2.6.28-rc2
 * [new tag]         v2.6.28-rc3 -> v2.6.28-rc3
 * [new tag]         v2.6.28-rc4 -> v2.6.28-rc4
 * [new tag]         v2.6.28-rc5 -> v2.6.28-rc5
 * [new tag]         v2.6.28-rc6 -> v2.6.28-rc6
 * [new tag]         v2.6.28-rc7 -> v2.6.28-rc7
 * [new tag]         v2.6.28-rc8 -> v2.6.28-rc8
 * [new tag]         v2.6.28-rc9 -> v2.6.28-rc9
 * [new tag]         v2.6.29    -> v2.6.29
 * [new tag]         v2.6.29-rc1 -> v2.6.29-rc1
 * [new tag]         v2.6.29-rc2 -> v2.6.29-rc2
 * [new tag]         v2.6.29-rc3 -> v2.6.29-rc3
 * [new tag]         v2.6.29-rc4 -> v2.6.29-rc4
 * [new tag]         v2.6.29-rc5 -> v2.6.29-rc5
 * [new tag]         v2.6.29-rc6 -> v2.6.29-rc6
 * [new tag]         v2.6.29-rc7 -> v2.6.29-rc7
 * [new tag]         v2.6.29-rc8 -> v2.6.29-rc8
 * [new tag]         v2.6.30    -> v2.6.30
 * [new tag]         v2.6.30-rc1 -> v2.6.30-rc1
 * [new tag]         v2.6.30-rc2 -> v2.6.30-rc2
 * [new tag]         v2.6.30-rc3 -> v2.6.30-rc3
 * [new tag]         v2.6.30-rc4 -> v2.6.30-rc4
 * [new tag]         v2.6.30-rc5 -> v2.6.30-rc5
 * [new tag]         v2.6.30-rc6 -> v2.6.30-rc6
 * [new tag]         v2.6.30-rc7 -> v2.6.30-rc7
 * [new tag]         v2.6.30-rc8 -> v2.6.30-rc8
 * [new tag]         v2.6.31    -> v2.6.31
 * [new tag]         v2.6.31-rc1 -> v2.6.31-rc1
 * [new tag]         v2.6.31-rc2 -> v2.6.31-rc2
 * [new tag]         v2.6.31-rc3 -> v2.6.31-rc3
 * [new tag]         v2.6.31-rc4 -> v2.6.31-rc4
 * [new tag]         v2.6.31-rc5 -> v2.6.31-rc5
 * [new tag]         v2.6.31-rc6 -> v2.6.31-rc6
 * [new tag]         v2.6.31-rc7 -> v2.6.31-rc7
 * [new tag]         v2.6.31-rc8 -> v2.6.31-rc8
 * [new tag]         v2.6.31-rc9 -> v2.6.31-rc9
 * [new tag]         v2.6.32    -> v2.6.32
 * [new tag]         v2.6.32-rc1 -> v2.6.32-rc1
 * [new tag]         v2.6.32-rc2 -> v2.6.32-rc2
 * [new tag]         v2.6.32-rc3 -> v2.6.32-rc3
 * [new tag]         v2.6.32-rc4 -> v2.6.32-rc4
 * [new tag]         v2.6.32-rc5 -> v2.6.32-rc5
 * [new tag]         v2.6.32-rc6 -> v2.6.32-rc6
 * [new tag]         v2.6.32-rc7 -> v2.6.32-rc7
 * [new tag]         v2.6.32-rc8 -> v2.6.32-rc8
 * [new tag]         v2.6.33    -> v2.6.33
 * [new tag]         v2.6.33-rc1 -> v2.6.33-rc1
 * [new tag]         v2.6.33-rc2 -> v2.6.33-rc2
 * [new tag]         v2.6.33-rc3 -> v2.6.33-rc3
 * [new tag]         v2.6.33-rc4 -> v2.6.33-rc4
 * [new tag]         v2.6.33-rc5 -> v2.6.33-rc5
 * [new tag]         v2.6.33-rc6 -> v2.6.33-rc6
 * [new tag]         v2.6.33-rc7 -> v2.6.33-rc7
 * [new tag]         v2.6.33-rc8 -> v2.6.33-rc8
 * [new tag]         v2.6.34-rc1 -> v2.6.34-rc1
 * [new tag]         v2.6.34-rc2 -> v2.6.34-rc2
 * [new tag]         v2.6.34-rc3 -> v2.6.34-rc3
 * [new tag]         v2.6.34-rc4 -> v2.6.34-rc4
 * [new tag]         v2.6.34-rc5 -> v2.6.34-rc5
 * [new tag]         v2.6.35-rc6 -> v2.6.35-rc6
From git://github.com/schandinat/linux-2.6
 * [new tag]         v2.6.34    -> v2.6.34
 * [new tag]         v2.6.34-rc6 -> v2.6.34-rc6
 * [new tag]         v2.6.34-rc7 -> v2.6.34-rc7
 * [new tag]         v2.6.35-rc1 -> v2.6.35-rc1
 * [new tag]         v2.6.35-rc2 -> v2.6.35-rc2
 * [new tag]         v2.6.35-rc3 -> v2.6.35-rc3
 * [new tag]         v2.6.35-rc4 -> v2.6.35-rc4
 * [new tag]         v2.6.35-rc5 -> v2.6.35-rc5
localhost linux-2.6 # git checkout viafb/viafb-s3v1
Previous HEAD position was 381ae24... Add the viafb video capture driver
HEAD is now at 7cc0ccf... viafb: add documentation for proc interface

I hope that this is correct git tree version.

Congratulations :) no rotation !!!

============
I didn't   believe - on the first sight it looks like vesa or vga.
However lsmod | grep fb shows only viafb
and no framebuffers are compiled in.

Thanks for testing :)
Normally I'd expect an "fbcon" to be there too. Is the use count of viafb (last number in lsmod) non-zero?
If it works, it looks like the sync had the wrong polarity.
I assume that it works only for native mode. Will try to fix this for non-native modes one day. That may take a while as in that case the real physical and fake physical resolution differs and the real physical resolution is what determines the correct polarity.
I've a good idea what might cause the lines out of screen you reported, essentially the entries in viamode.c are a bit wrong, I think. However fixing this will need the dynamic PLL value generation which is in itself very complex. I hope that I can get this fixed in 2.6.38.
Finally the downscaling code....well, I fear this one will get a WONTFIX as (I think) I don't have documentation that describes it, it won't be possible to implement it with an reasonable amount of work.

Hi, I am not sure what is going on.

Without vmalloc: (no rotation)

lsmod | grep fb

viafb                  55498  0 
i2c_algo_bit            5395  1 viafb
cfbcopyarea             2986  1 viafb
cfbimgblt               2105  1 viafb
cfbfillrect             2706  1 viafb

dmesg | grep fb

system 00:0d: [mem 0xffb00000-0xffbfffff] has been reserved
viafb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
viafb 0000:01:00.0: PCI INT A disabled
viafb: probe of 0000:01:00.0 failed with error -12    

With vmalloc=150M there is rotation :(

lsmod | grep fb

viafb                  55498  1 
i2c_algo_bit            5395  1 viafb
cfbcopyarea             2986  1 viafb
cfbimgblt               2105  1 viafb
cfbfillrect             2706  1 viafb

dmesg | grep fb
system 00:0d: [mem 0xffb00000-0xffbfffff] has been reserved
viafb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i2c i2c-0: adapter [viafb i2c io_port idx 0x26] registered
i2c-dev: adapter [viafb i2c io_port idx 0x26] registered as minor 0
i2c i2c-1: adapter [viafb i2c io_port idx 0x31] registered
i2c-dev: adapter [viafb i2c io_port idx 0x31] registered as minor 1
i2c i2c-2: adapter [viafb i2c io_port idx 0x2c] registered
i2c-dev: adapter [viafb i2c io_port idx 0x2c] registered as minor 2
viafb_init_dvi_size: DVI panel size undetected!

Ah, it was too good to be true to have this issue solved.
Yes that we still need vmalloc is an issue, too, but one that is not really solvable without limiting the framebuffer capabilities.
Okay so either the polarity was not the issue or we still do not set the desired one. I will think some time about it. I'm confident that the infrastructure changes reached a point where it should be possible to narrow the issue down, but that might require a few tests.

Hi,
I am very sorry,
after a few months gap my information is not very precise.
Let me explain :)

1. these last tests were for LCD screen, resolution 800x480
2. There is NO ROTATION
   (we have used "rotation" term when "bottom lines were at the upper edge of 
    the screen)
    However "some lines at the bottom are outside the screen" when vmalloc=150M
    (also when viafb_lcd_panel_id=8 is set)
3. without vmalloc parameter all lines are on the screen

It looks that without vmalloc parameters the viafb driver is not working.
But, there is no other framebuffer driver loaded or compiled in.
So, which driver is responsible for text console in this case?

Ah, no problem. I'm sorry that it took me so long to come up with a solution.

2. So if I understand it right it is an improvement after all. That's good :)
As I said the problem with lines out of the screen might get fixed "soon", as I have a very good idea what causes it and can reproduce similar behavior.

Yes that's correct, without vmalloc viafb is not working, probably I should add a workaround for this...
What you see in that case is probably vgacon which should work nearly everywhere on the x86 architecture. But it does not support higher resolutions, different output devices and other features.