profile
viewpoint

nomelif/Audionodes 60

Audio generation in blender nodes

ollpu/kk-lista 4

A checklist for competitive programming (in Finnish)

ollpu/cod 3

Persistent app state management in Rust without lenses.

ollpu/cpp-text-templates 2

Create template text files that can have C++ code in them.

ollpu/material-tempo 1

A neat looking and useful Android Tempo (BPM) Tapper made with material design standards in mind.

PullRequestReviewEvent

Pull request review commentRustAudio/cpal

Faster sample format conversion

 unsafe impl Sample for f32 {      #[inline]     fn to_i16(&self) -> i16 {-        if *self >= 0.0 {-            (*self * i16::MAX as f32) as i16-        } else {-            (-*self * i16::MIN as f32) as i16-        }+        (*self * F32_TO_16BIT_INT_MULTIPLIER).floor() as i16

Yeah, they should be consistent with each other, but I think a symmetric version makes more sense in general.

RamType0

comment created time in 9 days

Pull request review commentRustAudio/cpal

Faster sample format conversion

 unsafe impl Sample for i16 {      #[inline]     fn to_f32(&self) -> f32 {-        if *self < 0 {-            *self as f32 / -(i16::MIN as f32)-        } else {-            *self as f32 / i16::MAX as f32-        }+        const POSITIVE_MULTIPLIER:f32 = 1.0 / i16::MAX as f32;+        const NEGATIVE_MULTIPLIER:f32 = 1.0 / -(i16::MIN as f32);

You removed the asymmetry in f32::to_i16 (which I think makes sense), why not here? (relevant post)

RamType0

comment created time in 9 days

PullRequestReviewEvent

issue commentRustAudio/cpal

[JACK] timing imprecisions

Unrelated to playback, but this should probably be start_cycle_instant: https://github.com/RustAudio/cpal/blob/7ff54f17a733b18b6c457e240f01e43f2c910632/src/host/jack/stream.rs#L336

Either way, the playback timestamp will not increase uniformly, because the period time is not an integer amount of microseconds (which is the precision of the timestamp provided by JACK). The sample clock (how many samples have been output so far) should be your ground truth when sample-level accuracy is required. CPAL could possibly provide that too, but for now you have to keep count of it manually.

the-drunk-coder

comment created time in 12 days

issue commentRustAudio/cpal

ALSA: Capture fails from certain devices: `snd_pcm_sw_params` returns EINVAL, triggered by MONOTONIC_RAW timestamps

The error probably originates here (called from here).

I don't really understand the purpose of that check – does it mean a device (or some layer in between) can only support a predetermined tstamp_type?

ssssam

comment created time in 12 days

startedgeom3trik/VIZIA

started time in 14 days

pull request commentRustAudio/cpal

Proposal: Duplex API

Why is JACK support in a separate branch (https://github.com/rustydaw/cpal/tree/duplex-jack) not included in this PR?

My thought was that it wouldn't make sense to collect all host implementations into this PR, so it's easier to review the design. Having one implementation as an example isn't a bad idea so I've incorporated it here now.

Apologies for leaving this PR hanging for so long – I was sort of hoping for some comments before continuing work on it. It should now be good to merge as-is, and other host implementations can be added in later.

ollpu

comment created time in 18 days

push eventRustyDAW/cpal

Roope Salmi

commit sha 154b1fb72c16e345279bc0c6870a28bb7f6da80d

Stub all hosts with duplex API

view details

Roope Salmi

commit sha 26a9e87b4d6507bb350c850661866831dc1ecec7

Initial implementation of duplex for jack Rebased with help from nyanpasu64. --- It almost compiles. Original (outdated) commit message: The way the temporary interlacing buffers are handled currently is not great. The root of the issue seems to be that JACK actually provides a callback that allows performing allocations on the realtime thread when buffer size changes, but this is not exposed as such in rust-jack. See: https://github.com/RustAudio/rust-jack/issues/137 The duplex implementation now mirrors input, and this panicks if buffer size becomes greater than the original. Co-authored-by: nyanpasu64 <nyanpasu64@tuta.io>

view details

push time in 18 days

push eventRustyDAW/cpal

Roope Salmi

commit sha 18e3beb34afb68ac70c9ceace89bab3bd576b5ae

Stub all hosts with duplex API

view details

Roope Salmi

commit sha e23ca29be10306873df4c0b1450841acdcb3c739

Initial implementation of duplex for jack Rebased with help from nyanpasu64. --- It almost compiles. Original (outdated) commit message: The way the temporary interlacing buffers are handled currently is not great. The root of the issue seems to be that JACK actually provides a callback that allows performing allocations on the realtime thread when buffer size changes, but this is not exposed as such in rust-jack. See: https://github.com/RustAudio/rust-jack/issues/137 The duplex implementation now mirrors input, and this panicks if buffer size becomes greater than the original. Co-authored-by: nyanpasu64 <nyanpasu64@tuta.io>

view details

push time in 18 days

push eventRustyDAW/cpal

Roope Salmi

commit sha 467714f04b721ca5ae9e47fece97a245b0301746

Stub all hosts with duplex API

view details

Roope Salmi

commit sha 07608139918cf28d04f8ba8e3ec5edeb6e4bce7b

Initial implementation of duplex for jack Rebased with help from nyanpasu64. --- It almost compiles. Original (outdated) commit message: The way the temporary interlacing buffers are handled currently is not great. The root of the issue seems to be that JACK actually provides a callback that allows performing allocations on the realtime thread when buffer size changes, but this is not exposed as such in rust-jack. See: https://github.com/RustAudio/rust-jack/issues/137 The duplex implementation now mirrors input, and this panicks if buffer size becomes greater than the original. Co-authored-by: nyanpasu64 <nyanpasu64@tuta.io>

view details

push time in 18 days

push eventRustyDAW/cpal

Roope Salmi

commit sha 897be4b1321077f13436d2e6733819b4bf00a8a8

Initial implementation of duplex for jack Rebased with help from nyanpasu64. --- It almost compiles. Original (outdated) commit message: The way the temporary interlacing buffers are handled currently is not great. The root of the issue seems to be that JACK actually provides a callback that allows performing allocations on the realtime thread when buffer size changes, but this is not exposed as such in rust-jack. See: https://github.com/RustAudio/rust-jack/issues/137 The duplex implementation now mirrors input, and this panicks if buffer size becomes greater than the original. Co-authored-by: nyanpasu64 <nyanpasu64@tuta.io>

view details

push time in 18 days

push eventRustyDAW/cpal

Marcel Märtens

commit sha 2993afeb560cf33c8a9ef9eb09b28b5aba9de081

update dependencies

view details

est31

commit sha 5cfa09042c629c1ba39bbac1a6ae9278847a9ac1

Merge pull request #547 from xMAC94x/update_deps update dependencies

view details

Franz Heinzmann

commit sha c5caae08e48ae5baea5f8e716d4c77b7c3c7876e

Add JACK support to README

view details

João Capucho

commit sha 52821d9c37dc39cb8f503443ff6fdb51411402bb

Fix alsa in some configs outputting bad audio This was introduced in 6b91485 and could cause issues with some alsa configurations like that of pipewire-alsa which caused the audio to be become weirdly distorted

view details

Marcel Märtens

commit sha f9720b9767351d37b5617f96b7302a25dd4aad8a

clippy fixes

view details

Marcel Märtens

commit sha a945d83ac73b38b0789c9114dee5aa068f529ca9

give each thread a unique name

view details

est31

commit sha fbc0f71e21bb7491797138fe107d27034b3c8e08

Merge pull request #548 from xMAC94x/clippy clippy fixes

view details

est31

commit sha e75e4b4b5f0fd9483f241d23abe60c8c517fc4b7

Replace set-env with new method set-env has been deprecated

view details

est31

commit sha 5837ceb58f2f30ff3b3aaf52111275cc7bab26e2

Merge pull request #562 from JCapucho/fix-alsa-distortion Fix alsa in some configs outputting bad audio

view details

est31

commit sha 25ffc25324fd2e01267d6b2f8c9adf8a2d5edcb4

Changelog for 0.13.2 and 0.13.3

view details

est31

commit sha 1b2469d0c1175250e1c7944b51e53f613671e987

Merge pull request #561 from Frando/patch-1 Add JACK support to README

view details

Roope Salmi

commit sha 833acbae6107104df13f8b4bdbcc751421c18839

Update to rust-jack 0.7 and simplify implementation With rust-jack 0.7, the buffer_size callback is moved to ProcessHandler. This reflects how it is actually called by jack: it is called synchronously on the process thread, but it is allowed to perform non-real-time-safe operations. In CPAL, this means that it is fine to reallocate the temporary interlacing buffers when buffer size changes. This removes the need for buffer splitting on the output stream type, and prevents panics when buffer size is made larger than initially on the input stream type. (for some reason, buffer splitting was not implemented for input previously)

view details

Marko Mijalkovic

commit sha d6236adb847a5e3ac9552fbb3743798b239a7ca8

Remove unimplemented size hint

view details

est31

commit sha b628b9d3bb1fc8222248be57038030c0b0797152

Merge pull request #575 from overdrivenpotato/master Remove unimplemented size hint

view details

est31

commit sha 47ef62d41392f39b2d55f5a672b6425c273c9b23

Merge pull request #567 from RustyDAW/jack-alloc Update to rust-jack 0.7 and simplify implementation

view details

Alex Moon

commit sha c349eb1477b7e49ba406e179eb3c4b04d7f80766

[ALSA] Improve stream setup parameters. * Always set period before setting buffer size, even if `BufferSize::Fixed`. * Set `start_threshold` based on `alsa::Direction` to avoid underruns on playback streams. Also refactor the return values of the set params functions to reflect their actual use and resolve some clippy warnings (including a logic error in `stream_timestamp()`).

view details

est31

commit sha 9503ab729e2c9a3911fe39d706b16091041ac004

Merge pull request #582 from strohel/alsa-setup [ALSA] Improve stream setup parameters.

view details

Rémi Lauzier

commit sha acd2476cd7e809acdf26d3d106bb6a492d934ebe

fix a rustc warning

view details

est31

commit sha e9931113095d91a6cfed47b411a681ad7ef9b717

Merge pull request #583 from remilauzier/master fix a rustc warning

view details

Rémi Lauzier

commit sha 6c78dce4c1a40356bf8f9df7204cce82e07adcdb

fix some clippy warnings

view details

push time in 18 days

push eventollpu/ckb-next

Roope Salmi

commit sha a9b26dc8b492348b0347f83f8b3c63be0b3be49e

Debug os_usb_control when EBUSY given

view details

Roope Salmi

commit sha d9c0d2635ca7157cf872c4fb45972c330c477348

Use bool flags

view details

push time in 18 days

push eventollpu/ckb-next

Roope Salmi

commit sha 0bf494d484801ef49ab67e3dcca9d087c12a2ac1

Temporary: debug os_usb_control when EBUSY given

view details

push time in 19 days

push eventollpu/ckb-next

Roope Salmi

commit sha 6498f326ba04e4cb2a8b239b79e81ef97322a84d

Lock dmutex in graceful_suspend_resume

view details

push time in 19 days

push eventollpu/ckb-next

Roope Salmi

commit sha e0410c7e42c2208f5288b9014c25350f33794bde

Lock dmutex in graceful_suspend_resume

view details

push time in 19 days

push eventollpu/ckb-next

Roope Salmi

commit sha 54cbf563ead77af55ffc297dcbc9cb1d8a2c63d0

Only check suspend on failed ioctl in input thread

view details

push time in 19 days

push eventollpu/ckb-next

Roope Salmi

commit sha 31dd9f5596ffe3ce28139c418674fd9445c91d77

Debug messages in graceful_suspend_resume

view details

Roope Salmi

commit sha 66c14ddab8a803962feac78b27c2a109ad2a9101

Retry usbclaim() for some time

view details

push time in 19 days

push eventollpu/ckb-next

Roope Salmi

commit sha e0c4f15a87e07fd0a9acdb5a3bdab94bd5f3e632

Temporary: Check status of all interfaces

view details

push time in 19 days

push eventollpu/ckb-next

Roope Salmi

commit sha ecbb17714767fbc8ed17f249530e6423ca1e6001

Call wait_until_suspend_processed() in _ledthread

view details

Roope Salmi

commit sha 15ba0d57686f4ecdf9855683ec69f1931b898d8e

Debug messages in graceful_suspend_resume

view details

push time in 19 days

push eventollpu/ckb-next

Roope Salmi

commit sha 9592056742584917334705ba66fed65605b27b16

Fix issues with suspend wakeup - In case drivers are unattached when waking from suspend, wait gracefully until they are reattached. If necessary, reclaim interfaces for usbfs. - Avoid communicating with a device from devmain and input threads before reactivate_devices() is done. This avoids issues where the device gets confused and no longer works properly even after a reset. Tested specifically on Scimitar Pro, hopefully at least has no negative effect on other devices.

view details

push time in 21 days

push eventollpu/ckb-next

Roope Salmi

commit sha d55bdca0edb8395539b2c014003947ba0564059f

Refresh timestamp after reactivating devices

view details

push time in 22 days

PR opened ckb-next/ckb-next

Fix issues with suspend wakeup

I have a Scimitar Pro, and have been experiencing issues around waking from suspend, similar to what is reported in e.g. #456, #652. It also occasionally completely locks up the daemon, and the system hangs indefinitely when trying to shut down (only SysRq / hard reboot works).

After a couple days of debugging, I isolated two mostly separate issues.

Kernel race condition, oops, lockup

Sometimes when waking from suspend, I get this in dmesg:

<details> <summary>dmesg output</summary>

[  104.480212] BUG: unable to handle page fault for address: 00000000000028a8
[  104.480231] #PF: supervisor write access in kernel mode
[  104.480239] #PF: error_code(0x0002) - not-present page
[  104.480248] PGD 0 P4D 0 
[  104.480260] Oops: 0002 [#1] PREEMPT SMP NOPTI
[  104.480272] CPU: 0 PID: 414 Comm: suspend Tainted: G           OE     5.15.11-arch2-1 #1 03010ffba27108079ccfa4d61c5b01422e5fb7c7
[  104.480286] Hardware name: LENOVO 20N2CTO1WW/20N2CTO1WW, BIOS N2IET90W (1.68 ) 07/06/2020
[  104.480293] RIP: 0010:_raw_spin_lock_irq+0x1a/0x60
[  104.480314] Code: 00 75 05 31 c0 89 c7 c3 e9 73 63 54 ff 0f 1f 00 0f 1f 44 00 00 fa 66 0f 1f 44 00 00 65 ff 05 5d c1 25 6a 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 17 31 c0 89 c2 89 c1 89 c6 89 c7 41 89 c0 41 89 c1
[  104.480324] RSP: 0018:ffffad5480e07d08 EFLAGS: 00010046
[  104.480335] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  104.480342] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000000028a8
[  104.480349] RBP: 00000000000028a8 R08: 0000000000000000 R09: 0000000000000000
[  104.480355] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0eb899db318
[  104.480361] R13: ffffa0eb874b2800 R14: 0000000000000000 R15: ffffa0eb93b4b000
[  104.480367] FS:  00007fa0891ec640(0000) GS:ffffa0f0f1e00000(0000) knlGS:0000000000000000
[  104.480374] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  104.480379] CR2: 00000000000028a8 CR3: 0000000106edc004 CR4: 00000000003706f0
[  104.480386] Call Trace:
[  104.480392]  <TASK>
[  104.480400]  hid_pre_reset+0x24/0x70 [usbhid 90776c292c081bf67094cf06e3f68ea13c994907]
[  104.480424]  usb_reset_device+0xba/0x250
[  104.480439]  usbdev_ioctl+0xac3/0x1370
[  104.480448]  ? destroy_async+0x1c/0xa0
[  104.480460]  ? destroy_async_on_interface+0xe4/0x110
[  104.480467]  ? current_time+0x3c/0x100
[  104.480478]  ? __fget_files+0x9c/0xd0
[  104.480492]  __x64_sys_ioctl+0x8b/0xd0
[  104.480502]  do_syscall_64+0x59/0x90
[  104.480517]  ? __audit_syscall_exit+0x255/0x2c0
[  104.480533]  ? syscall_exit_to_user_mode+0x23/0x50
[  104.480545]  ? do_syscall_64+0x69/0x90
[  104.480554]  ? do_syscall_64+0x69/0x90
[  104.480562]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  104.480577] RIP: 0033:0x7fa08933a59b
[  104.480587] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a5 a8 0c 00 f7 d8 64 89 01 48
[  104.480596] RSP: 002b:00007fa0891ebcf8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[  104.480608] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa08933a59b
[  104.480616] RDX: 0000000000000000 RSI: 0000000000005514 RDI: 0000000000000006
[  104.480622] RBP: 00007fa0891ebd20 R08: 0000000000000000 R09: 00007fa0891eba00
[  104.480629] R10: 0000000000000000 R11: 0000000000000206 R12: 00007ffdc6c227de
[  104.480636] R13: 00007ffdc6c227df R14: 0000000000000000 R15: 00007fa0891ec640
[  104.480650]  </TASK>
[  104.480655] Modules linked in: ccm rfcomm cmac algif_hash algif_skcipher af_alg snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device bnep uinput uvcvideo videobuf2_vmalloc btusb btrtl videobuf2_memops btbcm videobuf2_v4l2 btintel videobuf2_common videodev bluetooth mc hid_corsair ecdh_generic snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel joydev mousedev soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp intel_tcc_cooling snd_sof x86_pkg_temp_thermal soundwire_bus snd_hda_codec_hdmi snd_soc_skl intel_powerclamp snd_soc_hdac_hda coretemp snd_hda_ext_core think_lmi iTCO_wdt kvm_intel snd_soc_sst_ipc intel_pmc_bxt ee1004 kvm snd_soc_sst_dsp intel_rapl_msr intel_wmi_thunderbolt wmi_bmof firmware_attributes_class iTCO_vendor_support snd_soc_acpi_intel_match mei_hdcp snd_soc_acpi snd_soc_core irqbypass snd_ctl_led snd_compress crct10dif_pclmul snd_hda_codec_realtek ac97_bus crc32_pclmul snd_hda_codec_generic snd_pcm_dmaengine
[  104.480849]  ghash_clmulni_intel aesni_intel snd_hda_intel crypto_simd snd_intel_dspcfg snd_intel_sdw_acpi cryptd iwlmvm rapl snd_hda_codec intel_cstate vfat intel_uncore mac80211 psmouse snd_hda_core fat snd_hwdep processor_thermal_device_pci_legacy libarc4 processor_thermal_device snd_pcm i2c_i801 processor_thermal_rfim e1000e snd_timer i2c_smbus thunderbolt iwlwifi thinkpad_acpi processor_thermal_mbox ucsi_acpi tpm_crb processor_thermal_rapl typec_ucsi intel_lpss_pci typec mei_me ledtrig_audio intel_rapl_common intel_lpss mei idma64 cfg80211 intel_soc_dts_iosf intel_pch_thermal roles platform_profile tpm_tis rfkill tpm_tis_core snd tpm int3403_thermal soundcore int340x_thermal_zone rng_core wmi int3400_thermal acpi_thermal_rel mac_hid acpi_pad vmw_vmci crypto_user fuse acpi_call(OE) bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 usbhid serio_raw atkbd libps2 sdhci_pci crc32c_intel cqhci sdhci xhci_pci mmc_core xhci_pci_renesas i8042 serio i915 intel_gtt video
[  104.481024]  ttm
[  104.481038] CR2: 00000000000028a8
[  104.481046] ---[ end trace 3eae0852d50f0142 ]---
[  104.481053] RIP: 0010:_raw_spin_lock_irq+0x1a/0x60
[  104.481070] Code: 00 75 05 31 c0 89 c7 c3 e9 73 63 54 ff 0f 1f 00 0f 1f 44 00 00 fa 66 0f 1f 44 00 00 65 ff 05 5d c1 25 6a 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 17 31 c0 89 c2 89 c1 89 c6 89 c7 41 89 c0 41 89 c1
[  104.481078] RSP: 0018:ffffad5480e07d08 EFLAGS: 00010046
[  104.481087] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  104.481093] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000000028a8
[  104.481099] RBP: 00000000000028a8 R08: 0000000000000000 R09: 0000000000000000
[  104.481105] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0eb899db318
[  104.481112] R13: ffffa0eb874b2800 R14: 0000000000000000 R15: ffffa0eb93b4b000
[  104.481120] FS:  00007fa0891ec640(0000) GS:ffffa0f0f1e00000(0000) knlGS:0000000000000000
[  104.481130] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  104.481138] CR2: 00000000000028a8 CR3: 0000000106edc004 CR4: 00000000003706f0
[  104.481147] note: suspend[414] exited with preempt_count 1

</details>

The crashed task leaves the device's (struct device) mutex locked forever, and further ioctls to the device from other threads go into uninterruptible sleep trying to lock it.

How I reproduced this consistently (>50%):

  1. Have some of the usbcore.quirks flags enabled in command line (b, g, n). I guess the delays make the race condition more likely to occur.
  2. Insert the device into a USB hub (in my case, a ThinkPad dock).
  3. Suspend. While asleep, unplug and replug the USB hub.
  4. Resume, boom.

The root cause here is a race condition on the USB interfaces. The kernel tries to reattach drivers while only locking the USB interface. Meanwhile, ckb-next-daemon issues an USBDEVFS_RESET ioctl to reset the device, which only locks the device itself (that is, these locks are separate and don't exclude each other).

Some pointers are left null during the driver reattach routine, which causes the "oops".

It is also problematic if the kernel reattaches the usbhid driver after we finish reactivate_devices(), even if an oops does not occur.

There's actually a very old warning in the documentation for USBDEVFS_RESET alluding to this:

Warning

Avoid using this call until some usbcore bugs get fixed, since it does not fully synchronize device, interface, and driver (not just usbfs) state.

I'll look into bringing up and fixing this in the kernel, but the issue seems quite broad so there's no obvious small fix.

Mitigation

This approach seems to avoid the race condition:

Call USBDEVFS_GETDRIVER. If it returns the error code ENODATA, it means there is no driver currently attached to the interface. As such, we should wait before issuing a USBDEVFS_RESET.

Once it returns a driver name successfully, if it isn't "usbfs" (us), then we should reclaim the interface.

On a cursory read of the kernel source, it seemed like USBDEVFS_GETDRIVER can return e.g. "usbhid" while the risk for the race condition still exists. In practice this didn't seem to happen, and I hope trying to disconect the native driver first (before USBDEVFS_RESET) synchronizes access to the interface correctly.

Inconsistent operation after suspend

The remaining issue is that some combination of functionality on the device doesn't work after suspend, though it is connected correctly through the daemon. Sometimes this is all functionality, sometimes only the macro buttons and LEDs on my Scimitar Pro. Even a reset of the device doesn't seem to fix it.

I pinned down the cause of this to the fact that some ioctls are issued to the device from other threads, before the suspend thread has had time to finish reattach_devices(). I don't fully understand the underlying mechanism, but the device somehow gets confused.

Fix

To fix this, all other threads use the same condition as the suspend thread to check if we have recently woken up. If so, they wait until the suspend thread is done with reattach_devices().

The suspend thread currently detects a wakeup by monitoring CLOCK_BOOTTIME and sleeping for two seconds at a time. If more than four seconds have elapsed, we deduce that a suspend happened (CLOCK_BOOTTIME advances during suspend). The other threads can look at the timestamp that the suspend thread last wrote, and use the same logic to detect the wakeup and then wait on a pthread_cond.


I'm only able to test this on my Scimitar Pro, so testing on other devices will be necessary. The only negative effect I can foresee is if an interface is left without a driver indefinitely after suspend (USBDEVFS_GETDRIVER gives ENODATA). In this case there is extra delay (set to five seconds) before the normal reset procedures run. I assume this scenario is possible at least with some USB quirks enabled?

+118 -6

0 comment

4 changed files

pr created time in 23 days

push eventollpu/ckb-next

Roope Salmi

commit sha a39129972cf04953cfbc4946dd637bc35098b9a0

Fix issues with suspend wakeup - In case drivers are unattached when waking from suspend, wait gracefully until they are reattached. If necessary, reclaim interfaces for usbfs. - Avoid communicating with a device from devmain and input threads before reactivate_devices() is done. This avoids issues where the device gets confused and no longer works properly even after a reset. Tested specifically on Scimitar Pro, hopefully at least has no negative effect on other devices.

view details

push time in 23 days

create barnchollpu/ckb-next

branch : suspend-fixes

created branch time in 23 days

fork ollpu/ckb-next

RGB Driver for Linux

fork in 23 days

issue commentollpu/tiralabra

[Security] Workflow coverage.yml is using vulnerable action actions/checkout

Thanks. I couldn't find any info on the vulnerability, could you send some pointers (perhaps privately by email)? I'm curious to know the full extent of this and whether I should take further action to mitigate.

Freakston

comment created time in a month

push eventollpu/tiralabra

Roope Salmi

commit sha 250a91aa3d3e150ee75555745e21e0a3aafb607c

Use checkout v2 Closes #2

view details

push time in a month

issue closedollpu/tiralabra

[Security] Workflow coverage.yml is using vulnerable action actions/checkout

The workflow coverage.yml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability. The vulnerability fix that is missing by actions version could be related to: (1) CVE fix (2) upgrade of vulnerable dependency (3) fix to secret leak and others. Please consider to update the reference to the action.

closed time in a month

Freakston
more