• Registered: 2010-06-21
  • Posts: 22

Topic: SDL on the Chumby One

Does anyone happen to have  a working instance of SDL compiled for the Chumby One? I have the Quake source that was configured for the original Chumby and, with a bit of work, have the version that I compile in the same shape that I was able to get the precompiled original with some work. That is to say that I have the application starting and have sound responds to the controls (shotgun blast upon clicking the stop button, ambient noise, occasional jump from tapping the screen). This seems to indicate that the alsa library and its SDL bindings are fine and that some game logic is happening under the hood. The main hinderance for me at this point seems to be that I am not getting any form of video-out to any of the framebuffer devices. A quick strace shows that the SDL init is opening /dev/fb0 and the debug info from the "stock" SDL from the chumby classic quake project shows "Checked mode 320x240 at 16 bpp, got mode 320x240 at 16 bpp".

I was just checking to see if this is a simple oversight whereby I've missed something pretty obvious or if it's a known issue that I should start digging through the library and throwing different "simpler" tests at SDL to see where the problem lies.

Thanks.

  • Registered: 2010-06-21
  • Posts: 22

Re: SDL on the Chumby One

Scratch that.

I found that the switch_output source posted by ChumbyLurker at http://forum.chumby.com/viewtopic.php?id=4283 had the FBIOPUT_VSCREENINFO call that set up the framebuffer properly for the way that the Quake source intended to render. I combined this with the code to switch to fb0 in the video initialization code of SDL and it worked without issue. The rendered scene does have a blue hue, though, but that could be a display format issue that I will look into later.

  • Registered: 2008-06-27
  • Posts: 518

Re: SDL on the Chumby One

There are several bugs in the chumby One kernel that were found and will be fixed in the next firmware build.

The first bug you ran into is that the kernel isn't passing the buffer size correctly.  If you switch resolutions first, like switch_output does, then the correct value gets populated.

The second bug you're running into is that the red and blue offets are backwards, which the chumby flash player ignores, but which SDL honors.  The easiest way to fix that is to hack SDL to swap red.offset and blue.offset.  The Right Way is to patch the kernel.

Both of these bugs, in addition to several involving TV output, will be fixed in future builds.

  • Registered: 2010-06-21
  • Posts: 22

Re: SDL on the Chumby One

Ah! Thanks for the details! Earlier I threw together a simple bitmap blit and saw that a color bar image was showing what you describe. Much more of a swap than a hue, but Quake had a tendency to be pretty red-heavy with the UI/lava. I agree about the kernel patching being the proper way to handle the fix, but do want to have the libraries and such that I build be able to run on a stock (but updated) device.

Tomorrow I'll have a look at swapping those offsets and then start looking into reimplementing the SDL controls regarding how accel / ts are handled differently on the C1. I know that it will take more coding/kludging than I've done thus far, but that is kind of the point of working on this. Today I compiled mpg123 with no real modifications so now I have a seekable MP3 player with ID3 tag info  as well. I'm really glad that I've finally been able to get some work done on my device from a coding standpoint.

My Insignia InfoCast arrives tomorrow, but I still have plenty of things to get implemented on the Chumby. I saw the mention of native-gcc on that device, which I greatly appreciate.

Thanks again for the information!