Fri 10 Dec 2010 06:37:25 AM UTC, comment #13:
No response, closing.
|
Fri 10 Jul 2009 05:49:11 AM UTC, comment #12:
Is this still a bug?
|
Sat 07 Jul 2007 08:28:56 AM UTC, comment #11:
Instead of SIGTERM you could try SIGINT. And you could start Gnash remotely via a network link, so you can see Gnash messages on the desktop monitor, and the graphics on the laptop.
|
Tue 31 Oct 2006 04:16:31 PM UTC, comment #10:
I'm not brave enough to try as SIGTERM still doesn't properly reset the framebuffer, even on my desktop computer, where I can get a 'gnash-working' setup (avoiding LUT seems to be enough)
|
Sat 28 Oct 2006 08:34:21 AM UTC, comment #9:
Does this problem still persist?
|
Fri 13 Oct 2006 02:40:44 PM UTC, comment #8:
Ok, I'll take a picture when I'm back home (no camera with me now)
|
Fri 13 Oct 2006 02:17:37 PM UTC, comment #7:
Hmm, no video mode in your kernel command line, but that may be required for vesafb only..
You can't make a foto of your screen, do you? ;)
At least, please try to describe the effect as much as possible. I have no clue what could be wrong
|
Fri 13 Oct 2006 01:22:50 PM UTC, comment #6:
root@xtops:/# dmesg | grep -F "Kernel command line"
Kernel command line: auto BOOT_IMAGE=7 ro root=1607 ramdisk=4096 apm=off acpi=on resume2=swap:/dev/hdc5 acpi_irq_balance acpi_irq_isa=3,12 hda=ide-scsi
root@xtops:/# dmesg | grep -F "fb:"
radeonfb: Invalid ROM signature 0 should be 0xaa55
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=195.00 MHz
radeonfb: Monitor 1 type LCD found
radeonfb: Monitor 2 type no found
radeonfb: panel ID string: 1400x1050 TFT
radeonfb: detected LVDS panel size from BIOS: 1400x1050
radeonfb: Power Management enabled for Mobility chipsets
radeonfb: ATI Radeon Lf DDR SGRAM 64 MB
I cited fb.modes just because I tried to add a "gnash" entry since the default mode ins't supported (8bpp). Anyway, it seems like that modeline doesn't really result in a different resolution
(since fbset still resports the 1400x1050 line)
|
Fri 13 Oct 2006 11:45:45 AM UTC, comment #5:
I'm not a expert, either, but fb.modes is not used in this case, AFAIK. I mean, you are booting in a graphics video mode, right? Even if the boot messages are text, they should be displayed using a graphics video mode.
Mmmh, please type:
dmesg | grep -F "Kernel command line"
dmesg | grep -F "fb:"
|
Fri 13 Oct 2006 11:28:01 AM UTC, comment #4:
mmm.. Indeed, fbset reports:
mode "1400x1050-83"
# D: 171.999 MHz, H: 91.489 kHz, V: 82.945 Hz
geometry 1400 1050 1600 1200 16
timings 5814 304 40 47 3 136 3
accel true
rgba 5/11,6/5,5/0,0/0
endmode
The point is that I cannot find such an entry in fb.modes
(I'm not a framebuffer expert)
|
Fri 13 Oct 2006 11:21:49 AM UTC, comment #3:
The snapshot looks correct.
Is 1400x1050 the native resolution of your LCD screen? Strange that fb.modes tells something different.
The rowsize is OK.
Note that FBGui does not change video mode, so it uses the same mode used by the text terminal. If that shows correctly, FBGui should also.
|
Fri 13 Oct 2006 10:34:16 AM UTC, comment #2:
With the new debugging output:
12:30:15: Framebuffer device uses 67108864 bytes of memory.
12:30:15: Video mode: 1400x1050 with 16 bits per pixel.
12:30:15: red channel: 11 / 5
12:30:15: green channel: 5 / 6
12:30:15: blue channel: 0 / 5
12:30:15: framebuffer pixel format is RGB565
12:30:15: initialized AGG buffer <0x44cb6008>, 67108864 bytes, 1400x1050, rowsize is 2800 bytes
Interesting enough, the snapshot is MUCH better then what I actually see !! (attached).
I see nothing this time, but the snapshot is correct :/
BTW, for future reference, the snapshot generator is 'fbgrab'
Another thing to note is that the 'fbi' application (fb-based image viewer) shows image colors incorrectly, so this might be my own kernel problem (linux 2.6.7)
|
Fri 13 Oct 2006 09:58:27 AM UTC, comment #1:
Please try with the current CVS version, it shows more debug info.
Sounds like the row size is not correct.
To make a snapshot of the framebuffer use:
cat /dev/fb0 > snapshot.raw
I have a little windows tool that can convert it to a PNG file, so just send the file to me, even if it's probably 2-3 megabytes.
Maybe this can be done using the "convert" tool, don't know. Or use the "fbdump" utility (haven't tested it).
|
Fri 13 Oct 2006 09:29:27 AM UTC, original submission:
On my laptop the fb/agg combination esults in bogus rendering.
I don't know how to take a snapshot of it (maybe we should add support for snapshotting in the FBGui class?) so can't show, but it's like sizes are wrongly detected (I see the image like interlaced, with the image really not recognizable at all, with lots of blank lines). gnash -v output follows:
11:22:30: Verbose output turned on
11:22:30: Framebuffer device uses 67108864 bytes of memory.
11:22:30: Video mode: 1400x1050 with 16 bits per pixel.
11:22:30: red channel: 11 / 5
11:22:30: green channel: 5 / 6
11:22:30: blue channel: 0 / 5
11:22:30: framebuffer pixel format is RGB565
11:22:30: agg_init()
11:22:30: AGG initialized.
The fb.modes line used is:
mode "gnash" # "1600x1200-66"
# D: 172.00 MHz, H: 82.700 kHz, V: 66.00 Hz
geometry 1600 1200 1600 1200 16
timings 5814 304 40 47 3 136 3
rgba 5,6,5
endmode
|