IXUS 310 HS (Elph 500 HS / IXY 31S) - available from the autobuild server - DryOS Development - CHDK Forum

IXUS 310 HS (Elph 500 HS / IXY 31S) - available from the autobuild server

  • 73 Replies
  • 56651 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Advertisements
Note:
CHDK for the IXUS 310 can be downloaded from the autobuild server (http://mighty-hoernsche.de/ or http://hacki.someserver.de/). These builds are created regularly from the latest version of the CHDK code.

==============================================================

Edit: 18th Aug 2011

Note: for DNG images Alpha 4 adds a simple compression method for the badpixel.bin file. It is compatible with existing badpixel.bin files so you don't need to re-create this. However on the camera I am using there are over 3x as many bad pixels in ISO 3200 as there are in ISO 100 - 1600. If you want to ensure bad pixels are always mapped out re-create the badpixel.bin file using ISO 3200. On my test camera the compression reduces the file size by ~45%.

Alpha 6 test version is now available at:
http://code.google.com/p/chdk-ixus310hs/downloads/list

Changes in Alpha 6:
- Fix ISO overrides not always working.
- Fix for RAW/DNG file names not always correct.
- Increase movie time limit to 2 hours (except for 1080p). The 4GB file size limit still applies so you aren't going to get 2 hours recording unless you decrease the video quality factor. The limit for 1080p was not changed because the camera gets quite hot recording this so I did not want to risk damaging cameras. Also for 120fps and 240fps the progress bar at the top of the screen still only counts to 30 seconds; but the movie will continue to record beyond this.

Changes in Alpha 5:
- Added firmware version 1.01a
- Fixed problem with touch screen code causing excessive power consumption.
- Added ND filter control override.
- Changed on-screen buttons to be transparent rather than filled. Less intrusive during video or 16:9 still modes.
- Added AE lock, ND filter and exposure controls to video recording. Note this is experimental and may cause the camera to crash.

Changes in Alpha 4:
- Fixed crash in continuous shooting if RAW/DNG enabled
- Added Manual Focus button controls in Alt mode
- Disable RAW/DNG in low light and high speed burst modes
- Buttons and button text are mode / context sensitive. E.G. up/down/left/right not visible unless in menu modes, 'Disp' button labelled 'Back' in menu mode (goes back one menu level in sub-menus), MF buttons only appear in Record mode.
- Compression of badpixel.bin file for DNG images (see note above).

Changes in Alpha 3:
- Fixed AV override crash if shutter button half pressed repeatedly too quickly
- Added setting toggle buttons in Alt mode to easily change common settings
- Improved touchscreen / menu stability (vanishes less often)

Changes in Alpha 2:
- Improved DNG color matrix.
- Removed support for partitioned SD cards > 4GB. The camera can boot CHDK directly on any size SD card so it is not necessary to mess around with partitioning for large cards. To make a card bootable, format the card in either the camera or computer, copy CHDK to the card, do a manual boot using the firmware update method, select 'Make card bootable' from the 'Miscellaneous stuff' menu. After it is done, turn off the camera, lock the card and CHDK will now boot automatically.

The U/I is a bit different to normal CHDK. To enter CHDK 'Alt' mode touch the 'CHDK' button on the screen. This will enter CHDK Alt mode and will then enable 'Menu', 'Set', 'Up', 'Down', 'Left' and 'Right' buttons on the touch screen. Use these to navigate CHDK as you would with a camera that has physical buttons. There is no touch interface on the actual CHDK menus or other parts so touching anything but the buttons won't do anything (yet).

If you want to put a Canon function in the spot occupied by the 'CHDK' button you can still activate it by holding the CHDK button for ~1/2 second - this will activate whatever action you have stored in the slot hidden under the CHDK button.

The following seem to work ok:
- RAW/DNG
- Movie quality override
- Exposure overrides (AV, TV & ISO)
- Scripts (uBasic and Lua), note however that the lack of physical buttons means that scripts that try to click buttons (like Menu & Set) will fail.
- Edge overlay, zebra & histogram
- PTP
- Autoboot and manual boot (via firmware update menu option)

Not implemented / working:
- Games, text reader & calendar
- JPEG quality override (the camera will allow SuperFine to be selected; but the file size is identical to Fine so no point)
- Support for partitioned cards > 4GB (you can still use a large card; but only with manual boot)

Known problems:
- CHDK on-screen buttons & menu may disappear sometimes. The CHDK on screen buttons should still work even if not visible.

==============================================================

Phil.
« Last Edit: 28 / October / 2011, 21:47:28 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #1 on: 15 / July / 2011, 21:21:19 »
I managed to work out how to detect that the touch screen had been touched and the X,Y position it had been touched at.
Using this I was able to create a 'virtual' button U/I that puts CHDK buttons on the touch screen - see attached image.

Amazing.   Simply amazing.

Doesn't the IXUS200-SD980 have a touch screen too ?


Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #2 on: 16 / July / 2011, 01:36:58 »
I managed to work out how to detect that the touch screen had been touched and the X,Y position it had been touched at.
Using this I was able to create a 'virtual' button U/I that puts CHDK buttons on the touch screen - see attached image.

Amazing.   Simply amazing.

Doesn't the IXUS200-SD980 have a touch screen too ?




Thanks :)

The IXUS 200 still has a rear dial, and buttons.
The IXUS 210 is the only other one I know of devoid of usable buttons.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #3 on: 16 / July / 2011, 06:03:46 »
I managed to work out how to detect that the touch screen had been touched and the X,Y position it had been touched at.
Using this I was able to create a 'virtual' button U/I that puts CHDK buttons on the touch screen


A simple question but maybe a complicated answer, how did you do that ?  :)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #4 on: 16 / July / 2011, 06:15:54 »
I managed to work out how to detect that the touch screen had been touched and the X,Y position it had been touched at.
Using this I was able to create a 'virtual' button U/I that puts CHDK buttons on the touch screen


A simple question but maybe a complicated answer, how did you do that ?  :)

Which bit - reverse engineering the touch screen or adding the virtual buttons?

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #5 on: 16 / July / 2011, 11:12:10 »

Which bit - reverse engineering the touch screen or adding the virtual buttons?


Both are of interest, let us start with the reverse engineering.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #6 on: 16 / July / 2011, 18:26:00 »

Which bit - reverse engineering the touch screen or adding the virtual buttons?


Both are of interest, let us start with the reverse engineering.

Started by displaying the physw_status values to see if any bits changed when the panel was touched. Only found one bit so I could detect the touch activation; but not the location.

I then searched for the string 'touch' in the firmware - one of the parameters to the DebugAssert function is the original source file name so this would at least give me a starting place to look for the code.

I found "TouchPanelDriver_TSC2008.c" being passed to DebugAssert which not only gave me the location of the driver code; but indicated that the touch panel might device might be named TSC2008. A google search on this found a Texas Instruments touch panel with this name and a downloadable spec sheet. From this I was able to get a basic understanding of the device (serial interface, returns seperate X & Y co-ordinates in either 8 or 12 bit resolution).

I also found a function that was calling the taskCreate function in the driver code - so this was most likely the touch panel firmware task. From this I got the memory address of the control structure being used to manage the touch panel (the memory block where most of the values are stored and retrieved from in the driver).

I then started displaying the various values from this memory block until I found things that looked useful - e.g. locations that consistently changed state when the panel was touched. Did not find anything here that looked like the co-ordinate on the panel that was touched so went back to the code.

Found another location in the code that was storing two 16 bit values that were being loaded from the IO area - this looked like a good candidate for the touched co-ordinates. They changed when the panel was touched; but not in any sensible way.

Back to the firmware and I eventually found a function that was doing conversion on the above two values. It was applying the function 'value = ((value & 0x7FFF) >> 5) ^ 0x3FF)'. Doing the same thing to these values when I displayed them and I got sensible X & Y co-ordinate values for the panel. From this I can see the resolution being used is 10 bits and a bit of experimenting showed me that the valid range is ~ 70 - 980 horizontally and 90 - 980 vertically (hopefully this is consistent on all cameras and not something that needs to be adjusted).

So now I could detect the panel being touched and where it was being touched.

I then tried various methods to block the touch events from the firmware - setting the bit in physw_status, clearing values in the main driver memory block, etc. These either did nothing or crashed the camera.

So finally I hooked the panel driver task into CHDK (like the other tasks being hooked) and copied the task code from the firmware. A bit of trial and error and I found where the touch events were being passed on to the rest of the firmware so I was able to block the events from reaching the firmware.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #7 on: 16 / July / 2011, 19:13:59 »

So finally I hooked the panel driver task into CHDK


That is all very interesting and very impressive.

OK, let us deal with the second part of the question ...

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #8 on: 16 / July / 2011, 19:18:22 »

Which bit - reverse engineering the touch screen or adding the virtual buttons?


Both are of interest, let us start with the reverse engineering.

Adding the on-screen buttons was fairly easy - although it's not a great U/I it does work.
This is work-in-progress, it has hard wired values that need to be moved to stubs_min.S; so will probably change quite a bit.

It basically extends the button handling in kbd.c to pretend that physical buttons are pressed.

First I added another value to the button state arrays and a variable to hold the CHDK state of the virtual buttons:
Code: [Select]
static long kbd_new_state[4];
static long kbd_prev_state[4];
static long kbd_mod_state[4];
static long touch_panel_state;

Then I added the virtual buttons to the keymap array. Since I also need to store additional info (co-ordinates and button name) I extended this structure:
Code: [Select]
typedef struct {
    short grp;
    short hackkey;
    long canonkey;
    short   x1, y1, x2, y2;
    char    *nm;
} KeyMap;

static KeyMap keymap[] = {

//  { 1, TOUCH_SCREEN   , 0x00000008 },                 // Touch screen panel
    { 1, KEY_ZOOM_IN    , 0x00001000, 0, 0, 0, 0, 0 },  // Found @0xff3d144c, levent 0x02
    { 1, KEY_ZOOM_OUT   , 0x00008000, 0, 0, 0, 0, 0 },  // Found @0xff3d1454, levent 0x03
    { 2, KEY_SHOOT_HALF , 0x00000200, 0, 0, 0, 0, 0 },  // Found @0xff3d1464, levent 0x00
    { 2, KEY_SHOOT_FULL , 0x00000a00, 0, 0, 0, 0, 0 },  // Found @0xff3d146c, levent 0x01
    { 3, KEY_PRINT      , 0x00000001,  70, 272, 180, 454, "CHDK" }, // virtual touch screen key
    { 3, KEY_MENU , 0x00000002,  70, 454, 180, 636, "Menu" },
    { 3, KEY_SET , 0x00000004,  70, 636, 180, 818, "Set" },
    { 3, KEY_UP , 0x00000010, 870,  90, 980, 272, "Up" },
    { 3, KEY_LEFT , 0x00000020, 870, 272, 980, 454, "Left" },
    { 3, KEY_RIGHT , 0x00000040, 870, 454, 980, 636, "Right" },
    { 3, KEY_DOWN , 0x00000080, 870, 636, 980, 818, "Down" },

    { 0, 0, 0, 0, 0, 0, 0, 0 }
};

The entries where 'grp' is 3 are the on screen buttons. The co-ordinates are the touch panel co-ordinates used to determine if the button is pressed; but are also used to position the OSD button display, the name is displayed inside the OSD button.

The code below is called from the touch panel task to process the touch events and work out which virtual buttons are pressed.
Code: [Select]
// Called from hooked touch panel task (boot.c)
// Return 0 to allow touch event to pass onto firmware, 1 to block event from firmware.
int chdk_process_touch()
{
    // If in canon menu, let the firmware have all the touch events.
    if ((canon_menu_active != (int)&canon_menu_active-4) || (canon_shoot_menu_active != 0)) return 0;

    // Touch co-ordinate
    unsigned short *t = (unsigned short *)(0x28f0);
    unsigned short tx, ty;
    tx = ((t[0] & 0x7FFF) >> 5) ^ 0x3FF;
    ty = ((t[1] & 0x7FFF) >> 5) ^ 0x3FF;

    // Search for CHDK on screen buttons matching co-ordinate
    int i;
    for (i=0; keymap[i].hackkey; i++)
    {
        if ((tx >= keymap[i].x1) && (tx < keymap[i].x2) && (ty >= keymap[i].y1) && (ty < keymap[i].y2))
        {
            touch_panel_state &= ~keymap[i].canonkey;
        }
    }

    // If in alt mode (or about to enter alt mode) block event from firmware
    return (gui_get_mode() != 0) || ((touch_panel_state & 1) == 0);
}

Finally the code below was added to my_kbd_read_keys, this copies the touch panel button state to the CHDK button state variable so that the various routines that check for key presses will detect these as CHDK button presses:
Code: [Select]
    if ((*((int*)(0x28bc+0x8))) == 2)               // Touch screen activated?
    {
        kbd_new_state[3] = touch_panel_state;               // Yes, use virtual button state
    }
    else
    {
        kbd_new_state[3] = touch_panel_state = 0xFFFFFFFF;  // No, clear out virtual button state
    }

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: IXUS 310 HS (Elph 500 HS / IXY 31S) - Touchscreen camera
« Reply #9 on: 21 / July / 2011, 08:05:22 »
Sample image of the current touchscreen U/I (3 screenshots stacked vertically).
Top image is normal shooting mode - CHDK 'Alt' mode button on the left.
Middle image - Alt mode activated, Menu and Set buttons appear along with setting toggle buttons on the right
Bottom image - Alt menu mode

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics


SimplePortal © 2008-2014, SimplePortal