Manjaro OS is booting and working remarkably well on Quartz64 model B. I can remember the early days of Pine64 and Rock64. It was a steep learning curve for developers and users. Improvements took eternity. As a desktop I find the system is very usable, albeit a bit slow in a graphics intensive browser.
Anyway I wanted to test bluetooth connectivity and performance. Both bluetooth devices were detected by Quartz and both connected to Manjaro/Quartz64. Unfortunately the sound is jittery and fragmented.
I recently bought a Pinephone Pro, and I've tried, without success, to work out where the software is to activate and operate the camera on the phone.
I've tried installing what I hoped might work from the Discover thing, but these seem to be for laptops. I have some clue about Linux, but I'm not an expert.
I've read threads from 2020 about the phone camera, and I assume they are out-of-date, so I'm at a loss as to even how to set up the basic things on the device, like privacy tools, and hardware like the camera. Can anyone point me to some quickstart guides please? I appreciate this might seem like a silly question, but I have to ask.
I just noticed that my new V2 has the same label on its housing as the V1.
Pics in the wiki show the V2 label has the expanded voltage and power range:
But mine still shows the same as the V1:
Bought from the Pine64 store (Order #247671) so I'm confident it's genuine and probably just the wrong case, but is there any way to check the hardware version without disassembling (lazy)?
From what I have seen (at least in the past), pinphones have hardware kill switches on the inside of the phone, it is located behind the battery or something.
Does the current version of the pinephone have hardware kill switches on the outside of the phone, like for example on the side of the phone, like the way how librem phones do?
or is this something planned in the next version of the pinephone?
It makes sense to put it on the side of the phone rather than on the inside as it allows the user to disable microphone, camera etc whenever they are not in use rather than having to open the back of the phone just to do this. For example if I am getting a call I would have to open the back just to turn the microphone on before answering the call, on the librem phone I can just flick the switch and then talk to the person.
Does pinephone have like this modular approach where if for example your camera is broken you can easily replace the camera with a replacement part yourself without needing a technician?
I cannot send/receive calls through my mobile carrier, but I have no problems with data or sending/receiving sms.
When I make a call it loads the xsmo menu for the call for one second, then terminates.
I have also tried this using manjaro-phosh, and the problem is the same, so I doubt its specifically a postmarketOS problem, but since I'm using postmarketOS I'm not sure if I can use openrc to get the error with the phone or what the best course of action is.
I have installed the firmware from https://github.com/the-modem-distro/pine...k/releases.
The modem log simply gives the timestamp saying call started then the phone number on the next line. Then the next entry gives the same timestamp one second later than the first and says call_finished with the same phone number I called.
I'm at a loss as to what to do. I did get a replacement board for this phone since the ram went bad in it and this sim card was working previously. I don't think there's a problem with how I installed the phone because like I said it is connecting to the mobile network and I can send/receive data and sms. However, I'm at a loss and about to give up.
with arch plasma, if the phone rings and the pinephone screen is on standby, I have to enter the phone’s pin code (not the sim card), and often it’s too late to take the call. What needs to be changed so I can take the call without giving the code as with phosh?
My old Sansa Clip finally bit the dust, and in looking for a replacement, it seems there is a dearth of decent, *uncomplicated* audio players on the market, unless you're willing to make some compromises.
Sony still makes awesome DACs, but their Walkman line is now Android-based, whcih is the opposite of what I want. I have plenty of devices to run apps. I just want a compact music player.
There's decent (enough) *hardware*, but the software for all of it sucks. After spending time looking at all my options on Amazon, it's obvious 99% of the market uses one of two firmwares, both of which suffer from some serious limitations that are entirely caused by bad code, not bad hardware.
This Chinese brand (SWOFY) clip MP3 player I picked up has the potential to be a lot better with relatively minor improvements to the firmware. The DAC isn't super great, but it's good enough unless you use big headphones and like bass-heavy music.
Maybe there's less of a market than I'm thinking here, but maybe Pine can consider developing an audio player with open-source firmware. If it's focused on audio-only, there's no need for expensive components like touchscreens and color displays; a monochrome OLED and physical buttons are preferable. Not only does this save money, it means better battery life. A good DAC is really what matters most, along with Bluetooth (as an audio output device) and USB-C (because micro-USB is not a resilient hardware connector and inevitably fails with enough use).
It's also something to consider for anyone who's concerned about tech privacy. A dumb music player can't track your location and phone home with details unique to your person, after all.
Some system-tools (e.g. udev, eg25-manager, ...) allow you to overload the configuration by placing a changed version below `/etc`. As long as the package maintainer does not adjust the original configuration this works fine. If the config is changed and you are not aware of that, your systems might behave "strange" (it no longer does the things you expect).
What is the best way to keep track of changes in config files where a cloned config was created?
My attempt is reflected in the attached file.
check_config_diffs.txt (Size: 2.31 KB / Downloads: 330)