mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #2462] Feature request: keyboard layout detection on first launch #953
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#953
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Jun 25, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/2462
I think the title is explicit.
It would be easier for non qwerty keyboard users not to have to map the keys by hand.
@hrydgard commented on GitHub (Jun 25, 2013):
Oh you mean like qwertz or azerty layouts? Post a link to code how to detect it and I'll add it.
@Daniel-Griffiths commented on GitHub (Jun 25, 2013):
On Android I dont think there is a way to detect the layout of the physical keyboard but you might be able to change the button layout based on device language.
@StorMyu commented on GitHub (Jun 25, 2013):
You can also Alt+Shift.... While having english set as second language, that's what i do with my azerty
Envoyé avec mon Smartphone BlackBerry® de Free
-----Original Message-----
From: BubblegumBalloon notifications@github.com
Date: Tue, 25 Jun 2013 06:07:57
To: hrydgard/ppssppppsspp@noreply.github.com
Reply-To: hrydgard/ppsspp reply@reply.github.com
Subject: Re: [ppsspp] Feature request: keyboard layout detection on first
launch (#2462)
I dont think there is a way to detect the layout of the physical keyboard but you might be able to change the button layout based on device language.
Reply to this email directly or view it on GitHub:
https://github.com/hrydgard/ppsspp/issues/2462#issuecomment-19974431
@ghost commented on GitHub (Jun 25, 2013):
@hrydgard I will look for that on the web.
However, I do bind myself in any way, as I'm really a beginner in C++.
@StorMyu Yes, this method at least works on Windows.
But I think it is even less constraining to set manually the keys via ppsspp controls window, as I don't switch between keyboard of different layouts.
Once everything is set, it is done, until the next development snapshot.
Thereupon, are PPSSPPControls.dat key mapping files compatible between versions?
@hrydgard commented on GitHub (Jun 25, 2013):
PPSSPPControls.dat hasn't changed yet, but may in the future. Mostly it will be compatible.
@ghost commented on GitHub (Jun 25, 2013):
@hrydgard Thank you for the information. From now, I will paste the file from a version to another. And I will pay attention to future changes in the controls.
@unknownbrackets commented on GitHub (Jul 8, 2013):
We did change it. It might be good to do better detection in the future, but how is the current situation for non-qwerty?
-[Unknown]
@hrydgard commented on GitHub (Jul 8, 2013):
PPSSPPControls.dat is dead now, configuration is in the .ini file. It's currently kind of ugly though.
Nonqwerty should be fine as everything can be mapped now. Maybe we can look at automapping by default later.
@Kingcom commented on GitHub (Oct 24, 2013):
This looks like it should help, on Windows at least: http://www.in-nomine.org/2012/08/06/detecting-keyboard-layout-used-on-windows/
It seems that it just returns the standard language IDs. My QWERTZ returnd 0x407 for example.
@hrydgard commented on GitHub (Oct 24, 2013):
Oh right, the QWERTZ problem, had forgotten about that. Yeah, so if we detect QWERTZ, let's map Cross by default to Y instead of X, that should be it, right?
@Kingcom commented on GitHub (Oct 24, 2013):
Instead of Z, yeah.
@hrydgard commented on GitHub (Oct 24, 2013):
Uh yeah sorry :)
@hrydgard commented on GitHub (Oct 24, 2013):
I pushed a simple change that tries to adjust for AZERTY and QWERTY. Report if something is missing, or we can close this.
@Kingcom commented on GitHub (Oct 24, 2013):
QWERTZ works fine!
For AZERTY, the triggers still need to be adapted. Left should be A and right should be Z.
@g2p commented on GitHub (Jan 24, 2014):
I prototyped a way to make it work on Linux and SDL2 platforms;
the layout is detected by looking at what keys the top row scancodes map to.
Is there an #ifdef SDL I could use in a pull request?
@Bigpet commented on GitHub (Jan 24, 2014):
We don't currently have defines for that. We currently use a CMake file and when
USING_QT_UIis not specified and we're not on a Win32 platform we just assume the use of SDL (and only then do we compile native/base/PCMain.cpp where the SDL input capture happens). It's all kind of outdated and SDL 1.2 based, afaik it was pretty much just a means to an end of getting it to run on some more platforms. We should update it to SDL 2.0 sometime, there was interest from someone in IRC but I haven't heard any updates.We could really use explicit defines though
@g2p commented on GitHub (Jan 24, 2014):
I've checked SDL 1.2, it's not so easily available (buried in X11 and alternative implementations, only exposed indirectly to translate keyboard events). Here's the prototype for later: https://gist.github.com/g2p/8597984
@Bigpet commented on GitHub (Jan 24, 2014):
@g2p thanks, I hope I remember it when we get around to updating SDL
@g2p commented on GitHub (Jan 28, 2014):
Layout detection will work for some users (for the three layouts we detect), but the preferred option would be to switch to scancodes. http://wiki.libsdl.org/MigrationGuide#Input explains about text entry vs using the keyboard as a giant pad. Unfortunately keycodes seem to be reimplemented multiple times in
native, so this would be a more intrusive change. IMHO, Android and Blackberry are likely candidates for using SDL abstractions instead of doing their own input handling.@hrydgard commented on GitHub (Jan 28, 2014):
Yeah, the keycode stuff is basically what was needed to get things working on Android, so it's possibly not general enough. Not sure what you mean by "multiple times" though.
Scancodes would be ideal but are not available on all platforms so we'll need a translation table from scancodes to NKCODEs.