Performance problem as 1920 pixels squashed into 1824

have you tried disable_overscan=1 in config.txt ?

I had similar problems on a Dell 2001FP after one of the firmware updates enabled overscan by default, messed with the fbwidth stuff as you have with little success. disable_overscan=1 sorted it for me.

Oh, and those double entries in /proc/cmdline are caused by the firmware blob supplying one set and cmdline.txt the others.  Only way to solve stuff added by the blob seems to be something in config.txt.

Like this:

root@raspberry-pi:~# cat /boot/cmdline.txt
dwc_otg.dma_enable=1 dwc_otg.dma_burst_size=256 dwc_otg.lpm_enable=0 dwc_otg.dma_enable=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 loglevel=7 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait


root@raspberry-pi:~# cat /boot/config.txt

arm_freq=800
enable_l2cache=1
disable_overscan=1
 
init_emmc_clock=50000000
 
root@raspberry-pi:~# cat /proc/cmdline
dma.dmachans=0x3c bcm2708_fb.fbwidth=1600 bcm2708_fb.fbheight=1200 bcm2708.boardrev=0x2 bcm2708.serial=0xc5116ef4 smsc95xx.macaddr=B8:27:EB:11:6E:F4 dwc_otg.dma_enable=1 dwc_otg.dma_burst_size=256 dwc_otg.lpm_enable=0 dwc_otg.dma_enable=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 loglevel=7 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait

Hooray, disable_overscan=1 did the trick, thanks selsinork!

Dunno how I missed that one, it must have been in the forums all over the place. :-(

I'm not seeing mouse or keyboard input loss anymore either.  That was really horrible.  And the pixels are as clean again as from my other machines now, no more moire patterning from the conversion.

Thanks again!

I'll try your speedups too now.

It's so easy to miss stuff like that..  They seem particularly disorganised with documenting stuff. You have to trawl github commit logs, the wiki in case someone's added it there and then all the comments on the front page blog and every post in the forums.  I find it very frustrating, information is there, it's just almost impossible to find.

My speedups ?   Not sure I've done anything like that...  That said, latest firmware and bootc's 3.2.21 kernel are definately worth a try!

I just meant the arm_freq=800 and enable_l2cache=1 that you listed as "speedups".  The freq's gone up.

I ran out of space on this little 2GB card so I hooked the Pi up to my NFS server, works fine.  About to test video now.

Ah.. I think the l2cache is enabled by default now and the arm_freq setting was part of the Arch image that I started with.  I'm not really to sort of person who goes in for overclocking, but this seems to work fine.

Don't know if you saw one of the videos from Maker faire where Eben strongly suggested that everyone in the foundation were running overclocked and overvolted

Do let us know how running over NFS works out. I've done it without problems, but have read about others having problems or crashes, possibly due to USB, or dodgy PSU..

NFS is working fine, I'm playing ogg albums over it, no audio glitches yet.  I put the same files on the SD card and on the NFS server, and they both play identically and use the same amount of CPU during playback:  27-29% for the current track.

However, I am seeing occasional pauses on xterm sessions while the audio is playing remotely.  That's not good at all, Linux hasn't suffered that kind of thing since the earliest days when schedulers were still ropey.  It could be the allegedly very poor USB driver going into hard spins I guess.  I hope not.

Morgaine.

I don't like single-core machines for running *nix.  They're not "slippy" inside, every little bit of rescheduling latency is always felt in user space rather than frequently hidden by another core already being ready to go and slithering over.

I think I might buy fewer Pi boards than I had planned (only use them for graphic interfaces, preferably Model A) and spend my money on dual and quad Cortex-A cores instead.  They'll always be more responsive even without considering their extra speed.

Morgaine.

It's definitely happening, loss of mouse events during audio playback over NFS.  (Never any audio glitch though.)

The way I'm testing it is simply by putting two xterm windows side by side and left-clicking them alternately while the music is playing, and counting the clicks.  If a click is missed then the window doesn't gain focus and that's immediately visible.  So far I always get a missed click before reaching a count of 30.  That's not good.

Addendum:  And the keyboard sometimes goes into autorepeat on pressing a character, which suggests a deschedule between press and release that gets interpretted as a long press, and hence activates autorepeat.  Not good either.  NFS is still playing great without a single glitch, so I guess it must be prioritized over interactive traffic, which is unexpected unless the kernel has been compiled for server operation.

Mouse clicks should never be lost regardless of the type of scheduling for which the kernel was compiled though.  That's clearly a fault on Pi.  When I get a moment I'll install Debian on the BeagleBone and replicate the same tests with audio played from an NFS server.  That should be very interesting.

Morgaine.

You've read the stuff about the USB port essentially having part of what really ought to be in hardware implemented in software ?  The 8000 interrupts per second and 20% cpu lost to doing it ?  From what I've read, you need to be able to catch all of those interrupts or you start losing key events (or worse). The repeating key thing is probably due to seeing the keydown event, but missing the keyup one.

I know there was some investigation being done into using some fancy interrupt thing, FIQ ?, to deal with a lot of the 8000 without dragging them all into the usb stack, but haven't heard anything about it for a while.

The whole usb thing, if not fixed fairly quickly, could become a messy problem.  I'm half inclined to go for Model A and an enc424j600 ethernet on spi because of it. I need ethernet for the things I'd like to do, but don't necessarily need it to be all that fast, hence considering it..