profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/dosemu2/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

dosemu2/dosemu2 283

Run DOS programs under linux:

dosemu2/fdpp 95

FreeDOS plus-plus, 64bit DOS

dosemu2/comcom32 17

32bit command.com

dosemu2/win31-mouse-driver 12

Universal (int 33h) mouse driver for Windows 3.1

dosemu2/msexpand 1

acts like Microsoft's EXPAND.EXE

starteddosemu2/fdpp

started time in 18 hours

issue commentdosemu2/dosemu2

problem with entering strings with accented characters via clipboard.

In -S mode (config layout = "es-latin1") is missing accent on deadkey character

Does the patch in the nearby thread somehow affect this?

fhanzlik

comment created time in 3 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

Mm, this patch could only help X with default layout. But as default layout is currently broken because of no dead keys, we seem to have no test case for the patch. :) Do you think we have a detection problem? Should it detect latin1 or should we fix es?

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

Mmm, looking back carefully at the results it seems no better, sorry.

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

With patch applied, layout = es-latin1, unmodified dosemu keymaps and sequence 'deadkey, shift + e'

X

C:\>E - deadkey is recognised, but no accent on character

SDL

C:\>É - deadkey is recognised and has accent on character

Progress I think!

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

Yes, what you say looks very plausible. So there is no problem with SDL, and yes it handles the dead keys on its own. In which case for X something like this may be needed:

diff --git a/src/base/kbd_unicode/serv_xlat.c b/src/base/kbd_unicode/serv_xlat.c
index fce123d6a..4570a0025 100644
--- a/src/base/kbd_unicode/serv_xlat.c
+++ b/src/base/kbd_unicode/serv_xlat.c
@@ -1650,7 +1650,8 @@ static void put_keynum(Boolean make, t_keynum key, t_unico
de sym,
                /* switch active keymap if needed */
                state->rules->activemap = state->rules->charset.keys[sym].map;
                ch = get_rule_ptr(key, state);
-               if (*ch != sym) {
+               if (*ch != sym && !is_keysym_dead(*ch) &&
+                               state->accent == DKY_VOID) {
                        k_printf("replace char %x with %x\n", *ch, sym);
                        *ch = sym;
                }

Could you please see what this patch does?

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

The es layout seems to have no dead key definitions

ERROR: key '
ERROR: key Left Shift
ERROR: key E

gives C:\>'É

Since Dosemu's es has no dead key definitions I wonder if in the example above SDL is doing the work to create the É before it's presented to dosemu?

But does sdl work properly for you if es is not the primary layout in X desktop? I.e. you were suggesting to drag it to the top.

No I mentioned that I set Spanish dead tilde layout to the top of the list so that the autodetection worked. In my case that chooses es-latin1 which does have dead key definitions and does work in SDL.

However es-latin1 doesn't work fully in X, it seems the dead key is effective in that it's not being printed, but the resultant upper case character has no accent, whereas lower case are fine. I did a little experimental tweaking of the es-latin1 keymap and I was able to make the correct character appear by changing the shift_map_es_latin1 as follows

diff --git a/src/base/kbd_unicode/keymaps.c b/src/base/kbd_unicode/keymaps.c
index 66fda5363..70815eb4a 100644
--- a/src/base/kbd_unicode/keymaps.c
+++ b/src/base/kbd_unicode/keymaps.c
@@ -1041,7 +1041,7 @@ CONST t_keysym shift_map_es_latin1[] = {
     'Q',    'W',    'E',    'R',    'T',    'Y',    'U',    'I',
     'O',    'P',    DKY_DEAD_CIRCUMFLEX,    '*',     13, U_VOID,    'A',    'S',
     'D',    'F',    'G',    'H',    'J',    'K',    'L', 0xefa5,
-     DKY_DEAD_DIAERESIS, 0xefa6, U_VOID, 0xef80,    'Z',    'X',    'C',    'V',
+     DKY_DEAD_ACUTE, 0xefa6, U_VOID, 0xef80,    'Z',    'X',    'C',    'V',
     'B',    'N',    'M',    ';',    ':',    '_', U_VOID,    '*',
  U_VOID,    ' ', U_VOID, U_VOID, U_VOID, U_VOID, U_VOID, U_VOID,
  U_VOID, U_VOID, U_VOID, U_VOID, U_VOID, U_VOID, U_VOID, U_VOID,

This is incorrect (and shouldn't be applied), but allows me to do shift + deadkey, shift + e = É whereas the proper sequence should be deadkey, shift + e = É

So I'm wondering if in the keyboard processing it's applying the shift state(required for the upper case) to the deadkey, and normally fails to match the key sequence. In my modified shift keymap the match succeeds and the character change occurs.

I believe that SDL is covering up this failure to match as it's already done the conversion, which is why we don't see the effect there. Does that sound plausible?

fhanzlik

comment created time in 4 days

issue closeddosemu2/dosemu2

Allow bindings for unpressable keys

It seems to be impossible to use DesqView in terminal mode, because there is no way to get the terminal to report an Alt press. You usually interact with DesqView by pressing Left Alt with no other key.

Maybe it would be useful to be able to map another key to unary Alt in dosemurc?

I thought a workaround might be using a TSR like scancode.com, that does work for some applications but apparently not DesqView. Maybe there is another trick I don't about!

closed time in 4 days

taviso

issue commentdosemu2/dosemu2

Allow bindings for unpressable keys

Ah-ha! That does seem to work, I had no idea that feature existed.

Thanks Stas!

taviso

comment created time in 4 days

issue commentdosemu2/dosemu2

Kernel 4.12 slow response in 16 bit mouse applications

Looks good!

severach

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

I'm still not totally convinced that there's anything actually wrong in SDL

Maybe something is wrong with es layout. But does sdl work properly for you if es is not the primary layout in X desktop? I.e. you were suggesting to drag in on the top. This may be a clue if it breaks otherwise.

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

Can you check that "es" has the dead deys properly defined?

Also please see what this gives:

diff --git a/src/plugin/sdl/sdl.c b/src/plugin/sdl/sdl.c
index 97a028112..368a11d09 100644
--- a/src/plugin/sdl/sdl.c
+++ b/src/plugin/sdl/sdl.c
@@ -1235,6 +1235,7 @@ static void SDL_handle_events(void)
                rc = 0;
            }
        }
+error("key %s\n", SDL_GetKeyName(keysym.sym));
        if (rc == 1)
            SDL_process_key_text(event.key, text_event.text);
        else

for dead keys.

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

Is this your 'A' a correct text that should be displayed?

Not quite sure on the log file ordering, but É is the correct character and further on it shows the correct unicode 0x00c9 for it.

I've updated the patch to log process key press also

index 97a028112..1186425bf 100644
--- a/src/plugin/sdl/sdl.c
+++ b/src/plugin/sdl/sdl.c
@@ -1185,6 +1185,7 @@ static void SDL_handle_events(void)
          error("SDL: missing key event\n");
          break;
        }
+       k_printf("SDL_process_key_text called(SDL_TEXTINPUT), event = '%s'\n", event.text.text);
        SDL_process_key_text(key_event.key, event.text);
       }
       break;
@@ -1235,10 +1236,13 @@ static void SDL_handle_events(void)
                rc = 0;
            }
        }
-       if (rc == 1)
+       if (rc == 1) {
+           k_printf("SDL_process_key_text called(SDL_KEYDOWN), text_event.text = '%s'\n", text_event.text.text);
            SDL_process_key_text(event.key, text_event.text);
-       else
+       } else {
+           k_printf("SDL_process_key_press called(SDL_KEYDOWN)\n");
            SDL_process_key_press(event.key);
+       }
       }
       break;

and uploaded the logfile as I'm not sure I was giving you enough context. t1.zip

This is specifying layout directly as es, auto detection normally selects es-latin which works correctly in SDL(deadkey is not printed), but wrong in X.

I'm still not totally convinced that there's anything actually wrong in SDL as long as the correct dosemu layout is used. I do find it strange though that I do have to use the other layout in X to have working dead key.

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

What layout does it detect in SDL mode?

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

Is this your 'A' a correct text that should be displayed? Then the "unexpected" char comes from the call to SDL_process_key_press(); from

<------>if (rc == 1)
<------>    SDL_process_key_text(event.key, text_event.text);
<------>else
<------>    SDL_process_key_press(event.key);

right?

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

In X11 mode, after ending interactive programs as edit or help, mouse cursor disappears in DOS window

Can confirm, both issues (mouse visibility and high CPU load) are now away. Thanks!

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

With this patch

diff --git a/src/plugin/sdl/sdl.c b/src/plugin/sdl/sdl.c
index 97a028112..e0b154bd9 100644
--- a/src/plugin/sdl/sdl.c
+++ b/src/plugin/sdl/sdl.c
@@ -1185,6 +1185,7 @@ static void SDL_handle_events(void)
          error("SDL: missing key event\n");
          break;
        }
+       k_printf("SDL_process_key_text called(SDL_TEXTINPUT), event = '%s'\n", event.text.text);
        SDL_process_key_text(key_event.key, event.text);
       }
       break;
@@ -1235,8 +1236,10 @@ static void SDL_handle_events(void)
                rc = 0;
            }
        }
-       if (rc == 1)
+       if (rc == 1) {
+           k_printf("SDL_process_key_text called(SDL_KEYDOWN), text_event.text = '%s'\n", text_event.text.text);
            SDL_process_key_text(event.key, text_event.text);
+       }
        else
            SDL_process_key_press(event.key);
       }

I see only one call

8042: IRQ ACK, 0                                                                
SDL_process_key_text called(SDL_KEYDOWN), text_event.text = 'Ã<89>'             
SDL: text key pressed: Ã<89>                                                    
move_keynum: keynum=0012                                                        
replace char 45 with c9                                                         
put_keynum_r: old_make:0 make:1 key:12                                          
translate_key: make=1, key=0012, input                                          
KBD: translated key = 00c9                                                      
KBD: writing to queue: scan=00000012                                            
fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

es (two printed, but second is correct)

Please see how many times SDL_process_key_text() is called and what is in text_event.text

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

Kernel 4.12 slow response in 16 bit mouse applications

This should now be fixed. I delayed the visibility change up to the cursor motion.

severach

comment created time in 4 days

push eventdosemu2/dosemu2

Stas Sergeev

commit sha 9ac5025bc7c53d801398c6173d74a3632434d4ec

emumouse: add option to lock visibility [#1545]

view details

Stas Sergeev

commit sha 71c8a2a56d3a031fd77798eb8beaaaa222e3a77e

mouse: delayed visibility change [fixes #1545, fixes #417] Some programs like edit.com like to flicker the mouse cursor a lot. This may slow things down, besides other bad things. Change real visibility only when mouse moves.

view details

Stas Sergeev

commit sha d7402eec84478c051d25e7b26dd8515514c186e2

int10: reset idle only on output funcs [#1545] This fixes the CPU hog (in edit.com) regression from 9a15687d2.

view details

push time in 4 days

issue closeddosemu2/dosemu2

Kernel 4.12 slow response in 16 bit mouse applications

In Norton Commander, arrow down a large folder. When the mouse is positioned over dosemu the keyboard response is slow and the mouse pointer flickers. Move the mouse away from dosemu and the keyboard response returns to normal.

Response is always fast in the command prompt with no mouse support and Foxpro with mouse support.

Downgrading to 4.9 solves the problem.

closed time in 4 days

severach

issue closeddosemu2/dosemu2

In X11 mode, after ending interactive programs as edit or help, mouse cursor disappears in DOS window

  1. When run dosemu2 (git 2021.10.18 g505b3f2bf) in desktop (MATE) terminal window as "dosemu -X" and then in DOS (FreeDOS 1.2) run "edit" (FreeDOS Edit 0.9a), then mouse cursor starts blinking, quickly (10+/sec) and erratic (the cursor is not visible rather than is). Still is possible to click on eg. menu item and it works. But after ending "edit", mouse cursor is in DOS window invisible. Selecting text by pressing the left mouse button and hovering over the text is still possible.

  2. when run FreeDOS Help (hhstndrd 1.0.5 en) in same way as above, it works and mouse cursor is visible. But after ending this help program, mouse cursor disappears from DOS window. Text selection is still possible.

closed time in 4 days

fhanzlik

issue commentdosemu2/dosemu2

problem with entering strings with accented characters via clipboard.

In SDL you need to hold shift.

Yes I was holding shift, but it now seems to me like SDL is not using X primary selection but something else. If in the source window I right click and use menu item copy the paste in to Dosemu works. I'll update the test above

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

non-ACSII/accented characters input with dead key

Revisiting my tests using different Dosemu layout

SDL

es (two printed, but second is correct)
BLASTER=A220 I5 D1 H5 P330 T6
MIDI=SYNTH:2 MAP:E MODE:0
C:\>'É
es-latin1 (correct)
BLASTER=A220 I5 D1 H5 P330 T6
MIDI=SYNTH:2 MAP:E MODE:0
C:\>É

X

es (two printed)
BLASTER=A220 I5 D1 H5 P330 T6
MIDI=SYNTH:2 MAP:E MODE:0
C:\>'E
es-latin1 (single, but is missing accent - will retry with lowercase in case it's a font problem)
BLASTER=A220 I5 D1 H5 P330 T6
MIDI=SYNTH:2 MAP:E MODE:0
C:\>E
es (lowercase prints two)
BLASTER=A220 I5 D1 H5 P330 T6
MIDI=SYNTH:2 MAP:E MODE:0
C:\>'e
es-latin1 (lowercase is correct)
BLASTER=A220 I5 D1 H5 P330 T6
MIDI=SYNTH:2 MAP:E MODE:0
C:\>é

So it seems to me that

  • dead key is possible in Spanish, but need to have a correct layout
  • X and SDL require different layout to work (not sure why this is)
  • É character needs further investigation in X as the unaccented char is printed (maybe font problem)
fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

problem with entering strings with accented characters via clipboard.

In SDL you need to hold shift.

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

problem with entering strings with accented characters via clipboard.

Not sure exactly, see what you think. Pasting this text (one char made with dead key, one just non ascii normal keypress)

Él escribe en español

X

In -X mode (autodetected es-latin1) shows this (note the first letter is rendered as two symbols, just as if typed)

C:\>´El escribe en español

In -X mode (config specifies $_layout = "es") it's correct

C:\>Él escribe en español

So my conclusion here is that the pasted text is somehow passed though the keyboard mapping to appear to DOS as if the keys were actually pressed, hence the layout has to match. I will revisit my X test from yesterday for #1544 now I know that I have to force layout to "es" not rely on auto detected "es-latin1"

SDL

In -S mode with either Dosemu layout I get nothing pasted at all, or if I had previously copied something in Dosemu window, the old text

fhanzlik

comment created time in 4 days

issue commentdosemu2/dosemu2

Allow bindings for unpressable keys

Resembles ZX-Spectrum's layout shiftings a bit. :)

taviso

comment created time in 4 days

issue commentdosemu2/dosemu2

Allow bindings for unpressable keys

All bindings are already there. They are probably not documented well. To get Alt, you need to press Ctrl-6 [release] Shift-a

taviso

comment created time in 4 days