Please help testing upcoming openMSX release!

Page 24/28
17 | 18 | 19 | 20 | 21 | 22 | 23 | | 25 | 26 | 27 | 28

By donluca

Expert (66)

donluca's picture

17-05-2020, 16:07

Manuel wrote:
donluca wrote:

Thanks for the link to github with the on-demand builds, I'll try them later.

That would be good to get more info about whether the CAPS lock issue depends on the build, the macOS version or some combination.

Can confirm that I have the exact same issue with the CAPS lock on the latest build made through Github.

By pgimeno

Master (136)

pgimeno's picture

18-05-2020, 02:34

I've found the cause of the font issue. It's due to this commit:

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/comm...

The rationale is explained here:

https://www.freetype.org/freetype2/docs/subpixel-hinting.html

which basically implies that it doesn't care much about fonts rendered at small sizes or on low resolution displays.

The workaround is to go back to the previous interpreter version, by setting this environment variable:

FREETYPE_PROPERTIES=truetype:interpreter-version=35

Under Linux, at least with sh and bash, you can set it for openmsx only by running it with this command line:

FREETYPE_PROPERTIES=truetype:interpreter-version=35 openmsx -machine etc etc

By pgimeno

Master (136)

pgimeno's picture

18-05-2020, 04:08

I missed a comma above, and it's too late to edit. I mean that if you want to run it only for openmsx without affecting other programs, i.e. without setting the variable permanently, you can run it with that command.

By sdsnatcher73

Paladin (882)

sdsnatcher73's picture

18-05-2020, 07:01

At the end of that freetype Explanation on sub pixel hinting it is recommended to use Liberation Fonts. Maybe this is a better way forward?

By Manuel

Ascended (16430)

Manuel's picture

18-05-2020, 10:55

See https://github.com/openMSX/openMSX/issues/1262 for the corresponding issue.

@ren: does setting that environment variable work for you to get the old rendering back?

By ren

Paragon (1393)

ren's picture

18-05-2020, 13:40

Juup, works, nice one @pgimeno!

Should revive the GH account, and add some of these new peculiarities to e.g. the FAQ.

Also thinking of tweaking the styling a bit of those manual pages: e.g. light & dark versions, another, more easy to the eye font face, improved link styling, increased line height etc.

By Manuel

Ascended (16430)

Manuel's picture

18-05-2020, 13:57

I encourage you to revive that account and submit Pull Requests Smile

Mth had the idea to set the environment variable to v35 if it isn't set yet. Then you can still choose, but by default we have the old behaviour.

By donluca

Expert (66)

donluca's picture

18-05-2020, 14:27

If I have time today I'll start downloading old openMSX builds to try and get to the bottom of the CAPS lock issue and see which commit is the culprit.
I saw you made a new ticket on github about this, let me know if you wish to further discuss this there.
I can also open another ticket for the compiling errors under macOS 10.13

EDIT: even with the oldest buildable macOS dev version the CAPS lock issue is present;

https://github.com/openMSX/openMSX/commit/747c042015e92c23e4...

There are no ready-to-go builds earlier than that for macOS.

By pgimeno

Master (136)

pgimeno's picture

18-05-2020, 17:16

@donluca: The cause has been identified by @Manuel. Apparently, Macs just do not report key up events for the caps lock key. There were two workarounds in past, one in SDL and one in OpenMSX:

  • The SDL one involved accessing an API that monitors every keypress from every application, and tries to guess when the application is focused so it can decide whether it should process the keypress or ignore it. In some version of the OS, however, this raised a security alert, because that can be exploited by keyloggers that monitor the passwords you enter in other applications. Therefore, explicit permission had to be granted to selected applications.

    But that one was removed from SDL when the permission request was implemented in the OS: https://hg.libsdl.org/SDL/rev/6a3b2cc9d66c

  • The OpenMSX one worked by considering the key active for about 100 ms, then synthesizing a key-up event. This was removed at some point, probably in the (wrong) belief that SDL did no longer need this workaround: https://github.com/openMSX/openMSX/commit/d18b9360d4da90879e... (it didn't... for a while, until it was removed from SDL).

So, the best fix is probably to reimplement that behaviour in openMSX. Unfortunately, it doesn't correspond to openMSX to implement a complete fix, and I don't think the SDL people will be willing to bring that patch back as an option. Of course there's some chance that Apple will cave and accept to provide an API that allows detecting the key release events for the caps lock key. Yeah, that joke wasn't even funny, sorry.

Note: All credits for the findings belong to @Manuel and @grauw. I'm merely reporting them.

By donluca

Expert (66)

donluca's picture

18-05-2020, 18:26

Crystal clear, thanks!

Page 24/28
17 | 18 | 19 | 20 | 21 | 22 | 23 | | 25 | 26 | 27 | 28