Search results

Yes, just let me know what the issues are in the bugtracker section of the forum. (although most likely I already know about them, but just haven't got around to fixing it)

The keyboard mapping is a huge mess of layer after layer of translations to get to the final output. It's a miracle it works at all :) (kernel key matrix output -> xkb pyra layout -> xmodmap , and after that funkeymonkey-pyrainput does a few things to it as well). It's another one of those...

The problem was that the current pyra kernel package is crosscompiled, which causes some of the non arm things to be included. I rebuilt the kernel package on arm hardware, which makes everything work like it's supposed to. After that the droidcam instructions on getting the kernel module built...

Yup, works. Still get the 6..1249 range thing though, (and continous output on 6) with most recent (last commit was 3 days ago) pyra_vol_mon from that repo. Did you ever figure out why reading the adc is so incredibly slow/cpu heavy ? All the other iio devices seem to have none of the issues...

It's Letux-5.6.19 with a few additional patches and a more debian compatible config. (We need aufs patched in for the dbp system, and the Letux config is very minimal) It was scraped together from various git repos, but never really properly commited anywhere. Exact source is here ...

Yes, I kind of rushed that post a bit, I should have added something like "Can this be backported to one of the kernels that's in a usable state" at the end there. Since you said it was integrated into LetuxOS, I assumed the driver+daemon was fully working, but I might have read that a bit too...

I gave it a try, First i applied the patches to the 5.6.19 kernel (since that's still the only one where everything (3d,screen,audio) works properly) Patch applied with a few tweaks, but i assume some more parts of the palmas_gpadc driver outside the iio got changed since that kernel. No...

Here's an image of the Pyra stuff modified slightly to run on the uevm : https://packages.pyra-handheld.com/images/extra/pyra-42-uevm.img.7z (extract the .7z, write to microsd, put microsd in uevm, resizing the second partition to fill the sd card is up to you) Since it's meant for the pyra...

Immediately after pressing the power button, do the leds next to the the power button light up green ? (to make sure it's the right uboot version)

The devicetree is selected by u-boot. It reads the version info from some resistors on the main and cpu boards, then selects the right dtb for that hardware. It shows the detected version on the serial output, in my case : HW Revision: CPU: v5.3 Mainboard: v5.2 Which it then turns into...

new gl4es version built and uploaded to the repo.

At least these are the actual commands, and not a "curl web.site/script.sh | sudo bash" some other sites tell you to use :)

No, the distro contains the public key, the repo signs with the private key, it wouldn't be very secure otherwise :) The "hack" above is because you can't get the new public keys through the normal method of the pyra-archive-keyring package, because you can't get new packages from the repo.

That's a different key. The one used to by the developer to sign the packages hasn't expired. The repo itself is also signed, and that key had expired.

Yes, I thought that key was set to never expire, but it seems it wasn't. Unfortunately there's no way to fix it from the server side. To fix it do: wget https://packages.pyra-handheld.com/pyra-public.pgp sudo apt-key add pyra-public.pgp After that, apt update/upgrade should work without...

It's connected to "voltage2" of palmas-gpadc , which has a very short section in the dts. kernel driver itself is at drivers/iio/adc/palmas_gpadc.c , which points to a few other places. I'm not sure what the other channels are used for, but if they're getting read from other places, it might be...

The main problems are caused by the kernel driver, which only does the bare minimum to get a sound stream going, without using any of the advanced features the chip supports. Getting a proper driver for everything is a lot of work. All the driver gives us is a 4 channel 32 bit/sample at 96khz...

The audio hardware isn't the cause of the volume wheel eating lots of cpu cycles though, that's to do with the AD converter taking forever to return the state of the volume wheel.

There's some basic led controls built in with " /usr/sbin/led-config" , which gets its config from /etc/default/leds , it's a very basic helper program around the /sys/class/leds interface. Not very userfriendly, and doesn't support any of the more advanced configuration option the leds class...

It's not that odd, it's because it's outputting incoming cursor key presses to the output keyboard AND joypad devices. So anything looking for keyboard and joystick events will see movement on both of them. It can be solved by telling FunKey to disable one of the output devices. In the end, it...