and from another thread:SDL, etc. is also not working properly yet
Yes, SDL fullscreen is not working yet.
Not sure if this helps:
At GPD Win I had to
Code:
export SDL_VIDEO_FULLSCREEN_DISPLAY=0
and from another thread:SDL, etc. is also not working properly yet
Yes, SDL fullscreen is not working yet.
export SDL_VIDEO_FULLSCREEN_DISPLAY=0
Hmm, in that photo the game art isn't rotated, from out point of view, which is what I'd expect to have happened given what you said. Looks more to me like the art is being drawn so that the width is the height of the screen, and the height is worked out proportionally from there. Probably the game does the latter automatically, but the initial mistake to me reads like it read the Y coordinate as the X coordinate. I'm slightly surprised the rest of the screen is still visible, and I don't know if it's still updating, but I've never seen the screen behind a fullscreen app before so I don't actually know what it's meant to look like. But it seems likely that some API needs to be tweaked to swap X and Y when giving the screen size, to account for the rotation in action. Which is kind of what you said, but using more words.@jakko, well it's not that full screen isn't working, it's just not drawing on the screen properly, as it's not accounting for screen rotation.
Forgive me if I’m barking up the wrong tree here but I thought @daveshah had already addressed this issue?Hmm, in that photo the game art isn't rotated, from out point of view, which is what I'd expect to have happened given what you said. Looks more to me like the art is being drawn so that the width is the height of the screen, and the height is worked out proportionally from there. Probably the game does the latter automatically, but the initial mistake to me reads like it read the Y coordinate as the X coordinate. I'm slightly surprised the rest of the screen is still visible, and I don't know if it's still updating, but I've never seen the screen behind a fullscreen app before so I don't actually know what it's meant to look like. But it seems likely that some API needs to be tweaked to swap X and Y when giving the screen size, to account for the rotation in action. Which is kind of what you said, but using more words.
Forgive me if I’m barking up the wrong tree here but I thought @daveshah had already addressed this issue?
Back when he addressed TILER rotation issue shortly before (or just after?) receiving the first dark chrome production Pyra?Umm... no? Where did you read that?
Ah. Ok!That's rotating the video data. There may be an API which is linked but rather orthogonal to that effort, namely an API to describe the dimensions of the screen, which is still giving the arguments in the wrong order.
The resistive touchscreen feels outdated in 2020 but is absolutely necessary to be used with a stylus ..
See ? That's a brand for pine64 phone. Instead of pinephones, they could have called them smartphines.smartphines
On-screen keyboards are very creative so it is not my achievement but theirSee ? That's a brand for pine64 phone. Instead of pinephones, they could have called them smartphines.
The touchscreen is nothing new - I mentioned that years ago already when we received the first touchscreens.
The problem is: As resistive touchscreens are not really used anymore these days, they don't have such a big surrounding frame as they used to have.
Unlike capacitive touchscreens, resistive ones can't be bonded on top of the screen - they need to be affixed around it.
Due to the minimum space on the screen where they can be glued to, the edges are affected a bit. ...
As usually, when using the OS most tend to use the nubs and as it's only at the edge of the screen, this was considered as being the best solution (no touchscreen or a capacitive one would've been the others).
Everything in the middle works fine, so for most games, etc. this is absolutely no problem. I wished I could've improved it, but that's when you try to combine modern tech (720p screen) with tech no one really uses anymore (resistive touchscreens).
Me too. People will have their preferences, but, on Linux (or any desktop environment) the actual problem is no software is really designed to be used with touch based interfaces.
For example, you won't be scrolling a pdf on Linux with touch, you will be tabbing or spacing through it because the kb is there and faster. Touch will force you to hunt and peck the scroll bar because the reader wont be expecting touch.
It gets worse if you want to draw or take notes.
It's going to get interesting as toolkits get revamped to include touch + responsive capabilities.
I just tested FF and a bunch of software on my Debian laptop and none of it actually scrolls on touch. Instead, the behaviour is left mouse click. I guess you can get the FF extension.
I am 100% Linux on everything, my laptop has touch. I don't know of a single application that interprets touch as anything other than left mouse click.
Are you using Ubuntu or a new compositor aware of touch or some other configuration?