It is currently Wed Jul 06, 2011 6:42 pm

All times are UTC - 8 hours




 Page 1 of 1 [ 8 posts ] 
Author Message
 Post subject: Hack in progress...
PostPosted: Fri Mar 04, 2011 5:30 pm 

Joined: Mon Feb 21, 2011 10:03 am
Posts: 26
Location: San Diego, CA
Here's a hack I'm working on - since the inPulse is limited with resources and connectivity, why not slave it to something that isn't quite as limited?

I ported a Bluetooth stack to Chumby, picked up a cheap USB bluetooth adapter at Frys, and wrote a simple program that does screenshots from the framebuffer, resizes them, and sends them to the watch. It takes about 4 seconds to transfer the entire image.


Attachments:

inpulsechumby.jpg [ 38.3 KiB | Viewed 568 times ]
Offline
 Profile  
 
 Post subject: Re: Hack in progress...
PostPosted: Fri Mar 04, 2011 6:54 pm 

Joined: Mon Feb 28, 2011 8:03 am
Posts: 7
neat idea!

I wonder if you could do something similar with a smartphone o_0


Offline
 Profile  
 
 Post subject: Re: Hack in progress...
PostPosted: Fri Mar 04, 2011 8:16 pm 

Joined: Tue Feb 15, 2011 6:42 pm
Posts: 26
Location: Ontario, Canada
Now that's cool!


Offline
 Profile  
 
 Post subject: Re: Hack in progress...
PostPosted: Fri Mar 04, 2011 8:56 pm 

Joined: Fri Feb 25, 2011 1:32 pm
Posts: 8
Duane, you never cease to amaze. Have it mirror a smartphone screen (or similiar) and you are golden.

Nice Chumby btw.


Offline
 Profile  
 
 Post subject: Re: Hack in progress...
PostPosted: Sun Mar 06, 2011 3:18 pm 

Joined: Mon Feb 21, 2011 10:03 am
Posts: 26
Location: San Diego, CA
The big problem with doing this on smartphones is that most don't allow you to capture the screen of one program from another program.

With only a few seconds of consideration, you can see why - this would be a *huge* security breach, even better than a keylogger. One could write an innocent-looking app that sets up a background service that continually captures the screen and sends it to some random server.

Android *used* to allow an app to open the framebuffer device and copy the data out of it, but they've allegedly closed that hole in newer versions. The "adb" tool development environment still allows you to capture the screen, but that's not a native Android application. There are some apps that allegedly can do screen shots - I'll look into them and see what they do.

If someone already knows how to capture the frambuffer image on a smartphone, please let me know.

The chumby allows this because it's *designed* to be hacked like this.


Offline
 Profile  
 
 Post subject: Re: Hack in progress...
PostPosted: Sun Mar 06, 2011 3:28 pm 

Joined: Sat Feb 19, 2011 3:34 pm
Posts: 5
Location: Mountain View, CA
Even if screenshotting isn't feasible on most platforms, it'd be awesome to have a reuseable way to pass images from devices to the watch, either for notification icons, or other imagery.

Is the code easily abstractable?


Offline
 Profile  
 
 Post subject: Re: Hack in progress...
PostPosted: Sun Mar 06, 2011 8:14 pm 
User avatar

Joined: Mon Feb 14, 2011 7:07 pm
Posts: 172
This is a wicked suggestion, and something that we need to implement natively in the SDK. At the moment, our packets are moving too slowly over the air to inPulse (and they're limited to 220b). Pretty crummy for image transfer.

Our next goal is to implement RFCOMM in our stack (replacing L2CAP). This will help everything out...make connecting much easier and hopefully will let us increase the baudrate. Unfortunately it's a bit of a large rewrite, so it might take a little while.

FYI we're using our own hacked up version of Matthias Ringwalds BTstack (http://code.google.com/p/btstack/). It's an excellent stack, and we've got it down to ~14kB program space, 2kB ram. If anyone has experience working with BT, let me know if you'd be interested in beta testing or helping with the RFCOMM hack.



_________________
---

Lead designer of inPulse
Offline
 Profile  
 
 Post subject: Re: Hack in progress...
PostPosted: Sun Mar 06, 2011 8:17 pm 

Joined: Mon Feb 21, 2011 10:03 am
Posts: 26
Location: San Diego, CA
jnjitkoff wrote:
Even if screenshotting isn't feasible on most platforms, it'd be awesome to have a reuseable way to pass images from devices to the watch, either for notification icons, or other imagery.

Is the code easily abstractable?


Yes- the watch end is really simple - it's basically exposing the watch's drawing API through Bluetooth.

There are three commands - clear the screen, fill a rectangle with a single color, fill a rectangle with the following colors.

There's no reason it can't be repurposed to show photos, etc.

I would probably add support for run-length encoding for at least *some* compression.

Here's the important part of the client part:
#define MAGIC 'C'

enum {
   CLEAR = 0,
   FILL_RECT = 1,
   FILL_PIXELS = 2
} commands;

typedef struct _command {
   uint8_t magic; // should be MAGIC
   uint8_t command;
   union _u {
      struct _fill {
         uint8_t left;
         uint8_t top;
         uint8_t right;
         uint8_t bottom;
         color24_t color;
      } fill;
      struct _pixels {
         uint8_t left;
         uint8_t top;
         uint8_t right;
         uint8_t bottom;
         color24_t colors[];
      } pixels;
   } u;
} __attribute__((packed)) command;
   
void handle_received_bluetooth_data(const uint8_t *buffer) {
    pulse_oled_set_brightness(100);
    pulse_update_power_down_timer(SLEEP_DELAY);
   command *c = (command *)buffer;
   if (c->magic==MAGIC) {
      switch (c->command) {
         case CLEAR: {
            pulse_blank_canvas();
            }
            break;
         case FILL_RECT: {
             pulse_set_draw_window(c->u.fill.left, c->u.fill.top, c->u.fill.right, c->u.fill.bottom);
            int count = (c->u.fill.right-c->u.fill.left+1)*(c->u.fill.bottom-c->u.fill.top+1);
            color24_t color = c->u.fill.color;
            while (count--)
               pulse_draw_point24(color);
            }
            break;
         case FILL_PIXELS: {
             pulse_set_draw_window(c->u.pixels.left, c->u.pixels.top, c->u.pixels.right, c->u.pixels.bottom);
            int count = (c->u.pixels.right-c->u.pixels.left+1)*(c->u.pixels.bottom-c->u.pixels.top+1);
            color24_t *color = c->u.pixels.colors;
            while (count--)
               pulse_draw_point24(*color++);
            }
            break;
         default:
            printf("BAD CMD %d\n",c->command);
            break;
      }
   } else {
      printf("BAD MAG %d\n",c->magic);
   }
}


..with the callback registered in main_app_init():

void main_app_init() {
    ....(other stuff)...
    pulse_register_callback(ACTION_HANDLE_NON_PULSE_PROTOCOL_BLUETOOTH_DATA, (PulseCallback)&handle_received_bluetooth_data);
}


What the chumby end is doing is reducing the 320x240 RGB565 down to 80x60 of color24_t, then sending the pixmap with two 40x1 pixel requests per scanline to keep the packet size under the limit.


Offline
 Profile  
 
Display posts from previous:  Sort by  
 Page 1 of 1 [ 8 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: