Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for opendingux beta build #3367

Closed
wants to merge 1 commit into from
Closed

Add support for opendingux beta build #3367

wants to merge 1 commit into from

Conversation

@citral23
Copy link

@citral23 citral23 commented Sep 14, 2021

Hello, I'd like to add support for opendingux (beta for now), which is a modern version of the operating system with kernel 5.15 (at the time of writing) and several enhancements over the past, unmaintained dingux.

https://github.com/OpenDingux

We support 3 flavors atm, jz4770 (called gcw0 for historical reasons) jz4760(b) (called lepus) and rs90, which I have not included here, with many devices supported.

This has been tested to run well on several jz4770 and jz4760 devices.

Signed-off-by: Christophe Branchereau cbranchereau@gmail.com

@ccawley2011
Copy link
Member

@ccawley2011 ccawley2011 commented Sep 14, 2021

I've haven't looked at this thoroughly, but there seems to be a lot of duplicated stuff from the existing Dingoo A320 and GCW Zero ports. Would it be possible to unify the two platforms somehow?

Also, AFAICT ScummVM currently only supports OpenDingux, with legacy Dingux support being dropped a long time ago, so could you clarify what has changed between the different incarnations of OpenDingux?

@citral23
Copy link
Author

@citral23 citral23 commented Sep 14, 2021

There are no real duplicates, I need to add a lepus .desktop file for instance, and mixing it all up with the legacy opendingux is not great for maintenance. Using the existing gcw0.desktop file could be possible, but it may well be subject to change in the future.

The existing gcw0/rg350 support was for the opendingux that shipped with the Anbernic devices, it is using a very outdated kernel and toolchain.

My proposal is to add support to current opendingux (otherwise known as opendingux beta) which is actively maintaned, has a GCC10 toolchain, and pretty much everything up to date to current standards. As such I can use different compilation flags, my own .mk file to compile with hugepages support and is the same for the two mips CPU variants, and so on.

Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com>
@citral23
Copy link
Author

@citral23 citral23 commented Sep 16, 2021

I have found some issues with my proposal, we're going to need our own complete backend instead of inheriting from the old dingux one.

What I can propose, is a reworked PR that drops completely the old dingux stuff + the gcw0 one (that doesn't even compile anymore) and replace it all with a clean opendingux backend, that will probably also compile fine with the old gcw0 toolchain.

It will probably take some time to test everything properly (for instance setting -DDINGUX enables a dirty toupper() hack that should probably be removed now, but I need to make sure it works without the hack, among other things)

@ccawley2011
Copy link
Member

@ccawley2011 ccawley2011 commented Sep 17, 2021

I have found some issues with my proposal, we're going to need our own complete backend instead of inheriting from the old dingux one.

What I can propose, is a reworked PR that drops completely the old dingux stuff + the gcw0 one (that doesn't even compile anymore) and replace it all with a clean opendingux backend, that will probably also compile fine with the old gcw0 toolchain.

It will probably take some time to test everything properly (for instance setting -DDINGUX enables a dirty toupper() hack that should probably be removed now, but I need to make sure it works without the hack, among other things)

This sounds reasonable, although I'm not sure what the limitations of the old backend were. It would be a good opportunity to get rid of the hardcoded key mappings that the old backend uses and replace it with the keymapper, similarly to what some of the newer backends do.

For reference, the existing dingux backend is currently compiled on our buildbot using a custom toolchain based on Docker and crosstool-ng, which uses GCC 9 alongside the original shared libraries to ensure that the C++11 engines can be built while still providing compatibility with older versions of OpenDingux. The sources can be found here and instructions on how to build using the docker images can be found here. Ideally, it would be good to have a docker image for the new toolchain as well, but this can be addressed later.

@sev-: Since you're currently maintaining the GCW0 port, what's your opinion on this?

@citral23
Copy link
Author

@citral23 citral23 commented Sep 18, 2021

Actually, your key mapper comment had me thinking I could probably get rid entirely of device specific code, and just add a mipsel host in configure to set host_os etc. and ./configure --host=mipsel, because od beta is just linux in essence.
Would still need to package it as opk, but that would be much cleaner then you could decide what you do with dingux and gcw0.

The main obstacle, is that char is signed by default on mips, and unless I compile with -funsigned-char I have a tolower() exception when adding a game, and even then a toupper() exception remains when pressing dpad left or right.

Edit: nevermind, I still need to map non-regular keyboard/mouse, will take inspiration from the switch or such to use the keymapper

@citral23
Copy link
Author

@citral23 citral23 commented Sep 21, 2021

I will close this PR, because I want to reparent my fork to scummvm/scummvm instead of being a fork of a dead fork.
I'll come back to you with a new, cleaner PR.

KR

@citral23 citral23 closed this Sep 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants