Can anyone point me in the right direction please?
> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-x86...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
>
>
As for the tablet, the video driver is right, and I can see it
switching to the VESA graphics from text at the mid-level of the debug
boot . {after the first exit, and before the 2nd}
ctrl-alt-f2 switched the console just long enough for me to type
dmesg, then it was gone for good. I tried f1,f2,f3 all fail to
switch, once it does the blinking cursor thing.
I'll check the kernel options tomorrow morning, but unless it's the
ACPI flag, it won't be that. I think something else is going on. The
way the cursor is blinking, it looks like it's trying to start a
process, failing, and starting over again. {a lot like an inittab
entry that doesn't stop spawning}
I do know that at that point ctrl-alt-delete reboots, and it is
instantaneous, it doesn't look like it is doing a typical runlevel
shutdown.
I'll toy with it some here and see what I can find.
Does anyone know how to change the display mode? {horizontal and/or
vertical refresh rates}
I'm not sure why it is changing the resolution after the kernel sets
it, but I'm starting to think there is a hard coded option somewhere
in the boot process.
Anyone have an idea now?
Changes I've tried:
probing i915 directly, with and without resolution options.
setting both uvesafb and i915 to not use mtrr
taking the probe out completely {panic}
vga=ask or xxx only affects vesafb driver.
If you are using i915 (inteldrmfb), set
video=wwwxhhh.
uvesafb (and its options) is only used
if no other framebuffer driver detected.
2010/11/29 Who what? <chan...@gmail.com>:
> Unfortunatly I was right on this one....
> /scripts/0-auto-detect forces 800x600-16 on the modprobe of uvesafb
> which probes the i915 driver itself.
> I've attempted to modify this several different times and ways, all of
> which either result in a kernel panic {as expected} or no change at
> all. I'm not familiar with uvesafb at all so I'm going to have to do
> a little research on this one.
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
I do know that vga= sets the old style vesafb {I did a lot of research
on that today}, thanks for that, I may not have gotten that far
looking things up by the time I had sent the email earlier this
morning.
However, when I do use the video= options at boot time, they are
forcibly overridden somewhere else. As far as I can tell that
override is after the module {i915/drm} load time. The script I
mentioned {/scripts/0-auto-dectect} is doing a set. It's the only
place I can find anything so far.
The problem is, if I remove the options there, when it probes the
module, it is still switching resolutions and/or sync rates when the
splash screen {andriod word with left to right highlights} comes up.
This one is weird for a couple of reasons.
1) Booting into debug mode for a prompt, no matter what I set the
kernel fb resolution to, it seems to work. Which gives me an
indication that everything should be fine.
2) Once the splash hits, whatever resolution I had, is reset to
800x600, and a sync rate that makes anything unreadable.
I'm still tracing through the entire startup process, but I haven't
found anything that should be causing this yet.
I'm now up to the full GUI and am happy. The USB is really laggy for
mouse imput and the acore keeps crashing but I will work through those
too.
Thanks for all the help everyone!
uvesafb and i915 are totally different fb drivers.
Saying uvesafb probes i915 is totally wrong.
i915 is usually detected and loaded by the auto-detect script.
uvesafb is only loaded if no other fb driver detected.
It is the last resort.
I think you're using i915, which is controlled by video= option.
As said, try cat /proc/fb to see what the fb driver is used exactly.
Never heard that and quite impossible.
The resolution is totally determined by the
framebuffer driver and related kernel options.
Android itself definitely won't change the resolution.
Remember Android is targeted for smartphone.
Have you ever heard a smartphone can
change its resolution? I never.
Check the output of logcat to see
the exact resolution you used.
BTW, have you enabled the hardware
OpenGL acceleration?