Silkscreen Does Not Work Under Pdaxrom On Sl-c1000

[Shmigol]

Silkscreen doesn't work under pdaXrom on SL-C1000. Maybe need change keycode in /etc/X11/kb/akita.xmodmap.

[Akitabara]

Same here. Can't change keycodes in xmodmap file because tapping the silkscreen icons doesn't trigger a keypress (xev doesn't report any event).

[Vitel]

Hi guys,

Yeah, it's known problem - corgi silkscreen patch is not applied for akita models by default. I've fixed it recently.

This is the list of differences between my patch and default patch for corgi:

1. 12 pixel in width bar is added between silkscreen buttons and display. There is no reaction on clicking on it. The aim of this feature is to avoid undesirable key clicking when you are scrolling in the landscape mode for example.

2. Added feature to allow clicking on one key two times in a row. It's locked in corgi patch, but I think it's useful. For example, we can bind one key to the following script to run/terminate virtual keyboard:
#!/bin/bash
if [ -z `ps aux | pgrep xvkbd` ]
then xvkbd -no-keypad
else killall xvkbd
fi

3. Key codes are changed to 121-125. The old keymap is uncomfortable because one of old key codes is equal to Shift_R button key code.

There are links to download
for Linux 2.4:
http://zavrik.ru/upload/xfree/beta3/fbdev.c.diff
http://zavrik.ru/upload/xfree/beta3/tslib.c.diff
http://zavrik.ru/upload/xfree/beta3/xfree_4.4.0_armv5tel.ipk
for Linux 2.6
http://zavrik.ru/upload/xfree/beta4/fbdev.c.diff
http://zavrik.ru/upload/xfree/beta4/tslib.c.diff
http://zavrik.ru/upload/xfree/beta4/xfree_4.4.0_armv5tel.ipk

You just need to remove old xfree package and install the new one. It's working for me, I hope It'll help you too

WBR,
Vitel

[zi99y]

Wow, excellent, has desertrat seen this he was asking about it too!

So is it safe to use on a C3200? I never remember my dog name...

thanks for looking into this

[zi99y]

WARNING: backup your old X11 config before you remove/reinstall this: I recommend taking a copy of everything in /etc/X11 and /usrX11R6/bin/startx script that may have been modified. Fortunately I thought of this first

Anyway I've tried it on my 3200 and it doesn't seem to work, when I use xev it doesn't show up keycodes, but, it does seem to react differently to the rest of the screen - I only had a short time to test before leaving for work so I will look into it further another time.

Vitel: Can you give us some detail on what has been patched as it may just need a little tweak for other models.

Ta

[kkazakov13]

I tested it, it's safe. Everything works as usual, now xev catches the silkscreen


thanks!

[zi99y]

I've been having a play and they do actually work! I am getting
responses from keycodes 121 - 125. The problem it seems is that if I
click key 125 (home) it acts as ctrl and locks on until you click
key 121 or 122 to remove the lock. This was very deceptive at first
because the keyboard went berzerk since every keypress was using the
ctrl modifier.

There's nothing in my xmodmap definition file or
/etc/sysconfig/keyboard/kernel.map that shows anything causing this.
Anyone else found the same issue or is it just my over-customised setup?

[desertrat]

Wow, excellent, has desertrat seen this he was asking about it too!

Yeah I saw this earlier and downloaded the ipk. But I haven't been brave enough to try it yet, because the last time I upgraded X it hosed my Xfce setup  
https://www.oesf.org/forums/index.php?showt...ndpost&p=104699

The problem it seems is that if I click key 125 (home) it acts as ctrl and locks on until you click
key 121 or 122 to remove the lock.

Could it be in any way related to this nasty problem?
https://www.oesf.org/forums/index.php?showt...ndpost&p=140368

[Meanie]

Wow, excellent, has desertrat seen this he was asking about it too!

Yeah I saw this earlier and downloaded the ipk. But I haven't been brave enough to try it yet, because the last time I upgraded X it hosed my Xfce setup  
https://www.oesf.org/forums/index.php?showt...ndpost&p=104699

The problem it seems is that if I click key 125 (home) it acts as ctrl and locks on until you click
key 121 or 122 to remove the lock.

Could it be in any way related to this nasty problem?
https://www.oesf.org/forums/index.php?showt...ndpost&p=140368
[div align=\"right\"][a href=\"index.php?act=findpost&pid=148438\"][{POST_SNAPBACK}][/a][/div]

if you are scared, all you need to do is extract the files from the ipk and just replace Xfbdev under /usr/X11R6/bin

[Akitabara]

The problem it seems is that if I click key 125 (home) it acts as ctrl and locks on until you click
key 121 or 122 to remove the lock.

Could it be in any way related to this nasty problem?
https://www.oesf.org/forums/index.php?showt...ndpost&p=140368
[div align=\"right\"][a href=\"index.php?act=findpost&pid=148438\"][{POST_SNAPBACK}][/a][/div]

I have the same issue. I've been tinkering a bit and I think it has something to do with Fluxbox too.

When I tap any of the silkscreen icons, the keyboard stops responding. It just locks - xev doesn't report keypresses, not even xvkbd works. For some reason the bottom row of app buttons and the Menu button still work, though.

Let's say I have this on ~/.fluxbox/keys:

Code: [Select]

None XF86Launch0    : exec aterm
None XF86Launch1    : exec aterm
None XF86Launch2    : exec aterm
None XF86Launch3    : exec aterm
None XF86Launch4    : exec atermI have aterm assigned to all silkscreen keys. When I tap e.g. the Calendar icon, aterm opens, but I can't type anything because the keyboard has been locked. Tapping any other icon opens the assigned program, but the keyboard stays locked. Only exiting X or restarting Fluxbox brings the keyboard back.

Now remove one of those lines from ~/.fluxbox/keys, e.g. the one for the Mail silkscreen button:

Code: [Select]

None XF86Launch3    : exec atermLaunch Fluxbox again. Nothing happens when tapping the Mail icon (as expected) but this time the keyboard doesn't lock. Note that the rest of the icons still open aterm and lock the keyboard, but only until you tap the Mail icon: it does nothing (because it has no action assigned) but the keyboard will unlock.

So this is the workaround I'm using: I chose the Calendar icon to unlock the keyboard, so I left the line regarding XF86Launch1 out of my ~/.fluxbox/keys file. After tapping any other icon I have to tap the Calendar one to be able to use the keyboard.
No big deal for me because all I wanted was a way to swap mouse buttons and open the Fluxbox rootmenu in PDA mode, but IMHO this issue needs a fix.

[pelrun]

Sounds suspiciously like a key release problem, and after looking at the code I'm certain of it.

The code isn't doing a simple key-down/key-up like I would have expected, it's trying something a bit more complex with timing involved, probably to allow a silkscreen key to be held down.

Unfortunately there's a bug - it now only releases a silkscreen button if another silkscreen button is pressed (oops.) It really should be releasing the key no matter what, unless the same silkscreen key is still being held down.

No guarantees if the following code is any better; it's 4am, I don't have anything set up to actually recompile X here, so this is just a rough stab. I don't even know when/how often tsread is called, especially after the stylus is removed from the screen.

Replace the entire block in tslib.c that begins:

Code: [Select]

if (event.y > hack_ts_max_y + 12) {with

Code: [Select]

    if (event.y > hack_ts_max_y + 12)
    {
  int code = 0;
  switch (event.x / (hack_ts_max_x / 5))
  {
      case 0: code = 113; break;
      case 1: code = 114; break;
      case 2: code = 115; break;
      case 3: code = 116; break;
      case 4: code = 117; break;
      default: break;
  }
  time_t currentts = time(NULL);
  if (currentts == lastts) return;
  if (lastcode != code)
  {
      if (lastcode != -1) KdEnqueueKeyboardEvent (lastcode, 0x80);
      KdEnqueueKeyboardEvent (code, 0);
      lastcode = code;
      lastts=currentts;
  }
  return;
    }
    else if (lastcode != -1)
    {
  KdEnqueueKeyboardEvent (lastcode, 0x80);
  lastcode = -1;
    }

[Akitabara]

Nice! I'd compile it myself, but I don't have t3h skillz yet...

[zi99y]

I don't really have the means right now either, but when I have the time I intend to setup a cross compile environment (I get mysterious errors compiling natively).

For the time being, leaving the middle button unmapped does seem to work as mentioned above, I just click it after clicking the other buttons to free up the ctrl lock

[Vitel]

Hi guys,

Sorry for the late reply.

Thanks to all of you, especially to pelrun.

Unfortunately there's a bug - it now only releases a silkscreen button if another silkscreen button is pressed (oops.) It really should be releasing the key no matter what, unless the same silkscreen key is still being held down.

I think you are right and this is the thing that exactly locks key pressing.

No guarantees if the following code is any better; it's 4am, I don't have anything set up to actually recompile X here, so this is just a rough stab. I don't even know when/how often tsread is called, especially after the stylus is removed from the screen.

I've modified code to provide "simple key-down/key-up". Old key code is no more stored, but timing is still remained to avoid following issue. TsRead function is called many times on every touchscreen clicking and if there is no any delay, then zaurus will have to execute binded action many times (for example, running some program). Therefore zaurus can freeze.
Thus each clicking of silkscreen keys will release pressed key and locking problem should not be reproducible now.

So, the new versions of patch and compiled xfree packages can be downloaded here:

for Linux 2.4:
http://zavrik.ru/upload/xfree/linux_2.4/tslib.c.diff
http://zavrik.ru/upload/xfree/linux_2.4/xf....0_armv5tel.ipk
for Linux 2.6:
http://zavrik.ru/upload/xfree/linux_2.6/tslib.c.diff
http://zavrik.ru/upload/xfree/linux_2.6/xf....0_armv5tel.ipk

I'm awaiting for your replies and hope this will work better.

WBR,
Vitel

[zi99y]

Many thanks for updating this, I've just extracted Xfbdev as per Meanies note above and replaced the old one and so far silkscreen is working fine without the previous glitch.

Cheers!