Linux Port
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
I guess it depends on how the image is put together, what license the component parts are under, and how it interacts with the Linux kernel which I’m assuming would be installed separately. Timothy knows what he’s doing with all this, so he can fill us in once he’s updated his repository with the new license. :) |
||||||||||||||||||
|
I sort of assumed it would be like a pre-built SD image that “would just run”? A more pertinent question may well be how it interacts with the kernel, but if that’s the case it would apply anyway regardless of how the software is started… |
||||||||||||||||||
|
There’s a chance that R.S might disagree ;) |
||||||||||||||||||
|
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.files on a filesystem don’t taint by proximity. [ https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html ] |
||||||||||||||||||
|
Also relevant from Linux:
|
||||||||||||||||||
|
Now that there is a RISC OS git client it’s possible to build the RISC OS Linux rom natively. The git client is available here. Clone the repository, sgit clone https://github.com/TimothyEBaldwin/RISC_OS_Dev.git RISC_OS_Dev or sgit clone git://github.com/TimothyEBaldwin/RISC_OS_Dev.git RISC_OS_Dev sgit makes no attempt to set file types at the moment. The file types can be set using !Rename available here. Drag the folder RISC_OS_Dev to the ‘Smart Renamer’ window and set it up as below, There is one file that needs copying manually otherwise the following error occurs building the rom,
Copy the file RISC_OS_Dev.Linux.Support.h.SocketKVM_Protocol to RISC_OS_Dev.Linux.Support.SocketKVM_Protocol/h Then build the rom using !Builder as normal. |
||||||||||||||||||
|
Ever since switching to the ‘Linux2’ branch, running RISCOSMark5 causes an abort and gives a ZeroPain error in the Basic module. |
||||||||||||||||||
|
I suspect that is because it tries identify the system by reading the name of the first HAL device, but currently the Linux Port has no HAL devices. |
||||||||||||||||||
|
Looks interesting. May be a good enough reason to go to using Linux more. Just a little hesitant to try it (oddly enough considering one of my current projects). Running on top of ARM Linux gets rid of the hardware support issues. I can not form a complete opinion yet, as I skipped a good part of this thread. |
||||||||||||||||||
|
It fails to build using an lxc container (arm on arm) complaining that; ’Can’t mount proc on /newroot/proc: Operation not permitted’ |
||||||||||||||||||
|
I read that by default LXC security settings prohibit mounting filesystems and other operations that are required create containers. Disabling these is may be unsafe for privileged containers, that is those that do not use user namespaces. I suggest you ask on a Linux forum if you need help setting up LXC to support nested containers. You can disable the sandbox using I have added instructions to the README.md file. |
||||||||||||||||||
|
I suggest you ask on a Linux forum if you need help setting up LXC to support nested containers. Thank you but it was just for your information. There was no nesting of containers here though, simply an lxc container running on an arm server, to prevent bloat of the host. I have added instructions to the README.md file. Cool. |
||||||||||||||||||
|
Aemulor on the Linux environment would be nice to have. |
||||||||||||||||||
|
Not sure if it’s documented. Attempting to change the mouse type from “Unrecognised” via the configuration screen results in some kind of lockup. |
||||||||||||||||||
|
No, there is, at least by some definition. The A solution I have found is to bind mount /proc/self instead of mounting a fresh procfs instance, however this breaks my parallel build modifications to srcbuild. I think that can be fixed by sharing the file descriptor table between processes. |
||||||||||||||||||
|
It works on ARM64 virtual servers running Ubuntu from Amazon Web Services, at last the search for cloud servers that can run RISC OS without CPU emulation is over. Unlike other cloud providers (eg Packet and Scaleway) who have brought 64-bit only processors they designed their own chips based on ARM’s 32/64-bit design. I haven’t tested the other Linux distributions, please note that it is possible to compile Linux without support for 32-bit programs. I discovered and fixed a few bugs:
I decided to make some benchmarks comparing Amazon’s smallest ARM virtual server to my desktop and laptop building RISC OS and running the following BASIC loop:
Amazon Web Services a1.medium51904.9 BASIC loops per second RISC OS build:
AMD A8-5600K on ASRock FM2A75 Pro4 with 2 × 4GB DDR3 CL9 1333MHz DIMMs122534.55 BASIC loops per second RISC OS build:
ASUS Chromebook C100P542202.75 BASIC loops per second RISC OS build:
|
||||||||||||||||||
|
Those found and fixed bugs… Those have been plaguing me forever. Thank you so much for fixing them! I came here today for another reason. Keymapping. I want to map the menu key on the keyboard to the menu mouse button. StrongKey doesn’t work in the Linux port. It thinks Toolbox is missing for some reason. Using StrongKey and Keymapper feels like it wouldn’t work anyway. What is the right way to do it? I cosidered altering keyboard.h but that may not yield the result I need. The trouble I have is that it’s a notebook keyboard so I can’t plug it into an RO system to work out if the scancode is mapped or as what. I tried trial and error with keymapper last night with no success. |
||||||||||||||||||
|
Whilst you might be able do it by altering Keyboard.h you shouldn’t as that is the list of RISC OS key numbers. For the SDL frontend the standard key mapping is specified in sdlkey.c and altered in sdl.cpp if the —chromebook option is given. It’s best add another option to sdl.cpp. You can find the list of SDL key names in the SDL header file. If you get stuck add " |
||||||||||||||||||
|
Thanks. I’ll give that a try later. StrongKey is adamant that Toolbox is missing for some reason so that’s a dead end. |
||||||||||||||||||
|
I tried adding an option for pinebook. Haven’t got that working yet for some reason. Added “{SDL_SCANCODE_APPLICATION, KeyNo_LeftMouse + 1},” to the scancodes in sdlkey.c and it appears to function. So at least it works the wrong way for now. |
||||||||||||||||||
|
It works for me once I load the tabs module, which is not part of the RISC OS distribution. |
||||||||||||||||||
|
Where are you getting the modules from? The versions I found bundled with something I can’t recall were too old for StrongKey. What I meant before is that I added an option for Pinebook that should have been selectable. via the commandline args. I didn’ have much time so I didn’get to investigate what I’d done wrong. But adding to sdlkey.c confirmed that there are no actual issues with getting the Pinebook option working besides me. |
||||||||||||||||||
|
See the announcement thread which states the Tabs module is available via PackMan. It just downloaded the linked zip file. |
||||||||||||||||||
|
I thought Tabs was an extension Toolbox module for the ROL originated Toolbox. Does it work with the standard release toolbox in RO5? |
||||||||||||||||||
|
I’ve uploaded a new version of StrongKey that includes the Tabs module and RMEnsures it correctly.
Yes, it works fine on RO5. I use it in several of my applications including one you should be familiar with, Transient (for its choices window). :-) |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15