I don't own one of these tablets but was looking at them, and saw that there's apparently no accelerarometer support. Has just iio-sensor-proxy been tested, or also something more modern like rot8?

Anybody else been having issues with the amdgpu driver crashing? Its been fine up until today, there was an update to the kernel and Mesa recently. So far it has only happened when watching YouTube in Firefox, it shows with garbled video, then the screen goes on and off and then sometimes it takes then gnome-shell with it dropping back to the gdm logon screen.

Thanks.

On Linux, the microphone of a headset plugged in via the audio jack does not produce any output.

Of course I have tried setting everything to max in alsamixer and tried all possibe profiles for this device.

This reddit comment seems to have the same issue:

https://www.reddit.com/r/linuxhardware/comments/1chqhc8/comment/l2pkjg2

I've installed Arch on my V3 and applied the soft mixing workaround, but the following does not work:

• Configure PipeWire to use soft mixing
• Reboot
• No audio output at all

But this does work:

• Boot with soft mixing disabled
• No audio output at all
• Change audio device profile to the other speaker one*
• Audio output works without volume control
• Configure PipeWire to use soft mixing
• Restart pipewire.service
• Audio output works with volume control

So, if my system boots with soft mixing enabled, the speakers will not work at all. Does anyone have an idea of what could cause this? My workaround for now will be to edit the configuration and restart pipewire automatically on boot.

*edit: found out the profile also needs to be changed

I see 5 audio devices on my Family 17h/19h HD Audio Controller:

• Play HiFi quality Music (Headphones, Mic1, Mic3) (unavailable)
• Play HiFi quality Music (Mic1, Mic3, Speaker)
• Play HiFi quality Music (Headphones, Mic1, Mic2) (unavailable)
• Play HiFi quality Music (Mic1, Mic2, Speaker)
• Pro Audio

Changing from whichever speaker profile is currently selected, to the other speaker profile, is the extra step mentioned.

Hi

In win 11 23h2.
If i flip the keyboard to the back of the V3, it will be disabled, normal, it's 'tent' mode, but normally, like tablet mode it must activate automatic rotation and it seems not ok on my unit.
(But work instantly if i disconnect keyboard)

I tried the BaseQi iSDA 750A adapter and it got stuck in the slot.

The reason is, that there are metal prongs which hold the SD card from the top. They get stuck in the microsd slot of the BaseQi adapter. I had to use a very thin lockpick (which I slid in between the adapter and the metal housing of the slot, to press that prong down with a diagonal sideways motion) to get it out.

Forcefully pulling the adapter out, would make the prong bend backwards, but probably won't damage anything else, you might be able to bend it back afterwards, but I'm not sure.

I tried it again with a microSD card in place and it still got stuck, because the microSD is not flush with the adapter.

Wanted to make this to gather other possible solutions people have tried and had success with. I can perhaps update this as I try things over the coming days. Out of the box I had ~5W idle draw on battery with Wi-Fi connected, power saver p-p-d mode enabled at 60 Hz and 0% display brightness.

Once I'm done digging around and perhaps refining some stuff (especially the ASPM script below) the plan is to just add this among the other information in the README doc.

My setup

Disabled SD card slot in BIOS (I don't have much use for it, should check if this affects things)
Chimera Linux (rolling release) with GNOME 46 on Wayland
Linux mainline kernel v6.10-rc6
power-profiles-daemon from git main for core performance boost control support
mesa from git main mostly for fun (I really should test if these things really matter for battery life at least)
power draw checked via upower -d, powerstat -d 2 or Vitals shell extension BATT rate monitor

Display panel

echo 0 > /sys/class/backlight/amdgpu_bl0/brightness, 100% scaling (in case that could've affected something under GNOME Wayland) @ 2560x1600 60 Hz I found the panel itself always seems to draw ~2.6 W/h even at these optimal conditions; maybe this is normal for an LCD of this size? Turning the display off for this test I achieved with:

dbus-send --session \
    --dest=org.gnome.ScreenSaver --type=method_call \
    /org/gnome/ScreenSaver org.gnome.ScreenSaver.SetActive \
    boolean:true

Switching from 60 Hz to 165 Hz seems to incur an additional draw of ~1.5 W/h, so at lowest brightness the display power draw alone would account for ~4 W/h

PCIe ASPM

It seems various PCIe devices have active-state power management disabled by default (as seen through e.g. lspci -vv | grep -E '(^[0-9a-z]|LnkCap|LnkCtl)' or in a more consice way lspci -vv | grep 'ASPM.*abled;'). Digging around I found pcie_aspm.policy=powersupersave can be added to kernel cmdline and upon reboot it's already looking much better (assuming the kernel is compiled with CONFIG_PCIEASPM_DEFAULT=y or similar, you can also check cat /sys/module/pcie_aspm/parameters/policy), though some like the Wi-Fi card and USB4 PCIe tunnel bridges were still missed.

So to finish it off I modified https://gist.github.com/baybal/b499fc5811a7073df0c03ab8da4be904 as follows to avoid in total at least a ~450 mW/h drain while idle without seemingly affecting the experience negatively (do report if testing and something breaks due to this!)

--- aspm_dell9360.sh
+++ aspm_v3.sh
@@ -43,8 +43,8 @@
 
 # You just need to modify these three values:
 
-ENDPOINT="00:1c.5"
-ROOT_COMPLEX="00:1c.4"
+ENDPOINT="c4:00.1"
+ROOT_COMPLEX="00:08.1"
 
 # We'll only enable the last 2 bits by using a mask
 # of :3 to setpci, this will ensure we keep the existing
@@ -255,21 +255,24 @@
 fi
 
 echo -e "${CYAN}Root complex${NORMAL}:"
-ROOT_COMPLEX="00:1c.0"
-enable_aspm_byte $ROOT_COMPLEX
-ROOT_COMPLEX="00:1c.4"
-enable_aspm_byte $ROOT_COMPLEX
-ROOT_COMPLEX="00:1c.5"
-enable_aspm_byte $ROOT_COMPLEX
-ROOT_COMPLEX="00:1d.0"
-enable_aspm_byte $ROOT_COMPLEX
-echo
+for root_complex in 00:02.2 00:03.1 00:04.1 00:02.3 00:08.1 00:08.2; do
+       ROOT_COMPLEX="$root_complex"
+       enable_aspm_byte $ROOT_COMPLEX
+done
 
+echo
 echo -e "${CYAN}Endpoint${NORMAL}:"
-ENDPOINT="3a:00.0"
-enable_aspm_byte $ENDPOINT
-ENDPOINT="3b:00.0"
-enable_aspm_byte $ENDPOINT
-ENDPOINT="3c:00.0"
-enable_aspm_byte $ENDPOINT
+
+ASPM_SETTING=3 # L1 & L0s
+for ep in c4:00.1 00:08.2 c5:00.0 c5:00.1; do
+       ENDPOINT="$ep"
+       enable_aspm_byte $ENDPOINT
+done
+
+ASPM_SETTING=2 # L1 only
+for ep in 00:02.2 00:03.1 00:04.1 02:00.0 ; do
+       ENDPOINT="$ep"
+       enable_aspm_byte $ENDPOINT
+done
+
 echo

As a result I can consistently idle without apps open on the GNOME desktop at around 4.2 W/h, better than stock but I think this can still be further driven down with other tweaks..

Keyboard case

Having the keyboard plugged in while doing nothing seems to draw:

• Without backlight enabled: ~100 mW/h
• Backlight at level 1: ~500 mW/h
• Backlight at level 2: ~830 mW/h
• Backlight at level 3: ~1.2 W/h
• Backlight at level 4: ~1.6 W/h

s2idle

Closing the "lid" with keyboard case connected without shutting down / otherwise triggering "suspend" on my end seems to drain at ~279 mW/h (or ~0.55%/h) so from 80% charge limit it would last just about 6 days, or about 7½ days from 100%. Would be interested to hear if this is in line with what others are seeing including on Windows with modern standby (perhaps that can also be tweaked to work better somehow?).

Waking up from s2idle (suspend) also seems to make the device draw ~300 mW/h more than before, I haven't tracked down yet what exactly this comes down to though; perhaps some ASPM configuration getting undone despite lspci -v not reporting so? -> check without any ASPM tweaking if this is still the case

Powered-off drain

It seems to have drained ~88 mW/h (or ~0.17%/h) so it should at least last just over 19 days fully shut down from 80% or nearly 24 days from 100%. I measured the energy Wh level from upower -d just before shutdown and just after booting after 8 hours, may not be the most accurate way since the device spends some power booting off/on after/before between those two invocations to check the current battery Wh level so this is likely a worst case scenario with some inaccuracy and it should be slightly better maybe.

Sorry to open this here, I don't do social media. Does anybody know of an alternative to the Baseqi 750A? I've looked on both Amazon and eBay and can't find any for sale and it seems to be out of stock on their own website too.

Thanks.

Hiya, dunno if this is the right place to share it, but this repo seems to be a good congregation point for this sorta stuff.

On arch linux, I tried to get the global volume controls to work, but the file location didn't work. after some time I got it to work, but there's probably a better way to do this:

in /etc/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf:

monitor.alsa.rules = [
  {
    matches = [
      {
        device.name = "~alsa_card.*"
        # factory.name = "api.alsa.pcm.sink"
      }
    ]
    actions = {
      update-props = {
        # Do not use the hardware mixer for volume control. It
        # will only use software volume. The mixer is still used
        # to mute unused paths based on the selected port.
        api.alsa.soft-mixer = true
      }
    }
  },
  {
  matches = [
      {
        node.name = "~alsa_output.*"
      }
    ]
    actions = {
      update-props = {
        # mic breaks w/o
        api.alsa.soft-mixer = false
      }
    }

  }
]

Hi

you tested fedora, I tried a few things (still testing) on pop!_os 22.04, thought it would be interesting to see the difference as you tested Fedora. Hope it's ok?

Everything seems to work out of the box, for now, with following caveats:

• fingerprint reader
  • I'm amazed as this works in fedora 40, verified this myself.
  • Still haven't gotten this to work. Would be interesting to know what Fedora implemented differently, for now, I haven't been able to resolve this.
• stylus buttons (but I haven't looked into resolving this)
• auto-rotate, but this can't be a surprise.

When I find a solution for these problems, i will post an update.
Probably will need to install Fedora again, for the fingerprint reader.