fix: Add handling for missing VideoFormat on Linux

[meocoder31099]

I am using COSMIC DE, which uses VideoFormat::RGBA instead of VideoFormat::BGRx like GNOME or KDE, so it leads to a panic "Unsupported frame format received".

In the current code, VideoFormat::RGBA is included in the list of output formats for the buffer

scap/src/capturer/engine/linux/mod.rs

Lines 213 to 222 in 92cabc5

	pw::spa::pod::property!(
	FormatProperties::VideoFormat,
	Choice,
	Enum,
	Id,
	pw::spa::param::video::VideoFormat::RGB,
	pw::spa::param::video::VideoFormat::RGBA,
	pw::spa::param::video::VideoFormat::RGBx,
	pw::spa::param::video::VideoFormat::BGRx,
	),

but the case where VideoFormat is VideoFormat::RGBA is not handled

scap/src/capturer/engine/linux/mod.rs

Lines 136 to 164 in 92cabc5

	if let Err(e) = match user_data.format.format() {
	VideoFormat::RGBx => user_data.tx.send(Frame::RGBx(RGBxFrame {
	display_time: timestamp as u64,
	width: frame_size.width as i32,
	height: frame_size.height as i32,
	data: frame_data,
	})),
	VideoFormat::RGB => user_data.tx.send(Frame::RGB(RGBFrame {
	display_time: timestamp as u64,
	width: frame_size.width as i32,
	height: frame_size.height as i32,
	data: frame_data,
	})),
	VideoFormat::xBGR => user_data.tx.send(Frame::XBGR(XBGRFrame {
	display_time: timestamp as u64,
	width: frame_size.width as i32,
	height: frame_size.height as i32,
	data: frame_data,
	})),
	VideoFormat::BGRx => user_data.tx.send(Frame::BGRx(BGRxFrame {
	display_time: timestamp as u64,
	width: frame_size.width as i32,
	height: frame_size.height as i32,
	data: frame_data,
	})),
	_ => panic!("Unsupported frame format received"),
	} {
	eprintln!("{e}");
	}

This PR will fix it.

[MAlba124]

Not safe for dmabuf, see the "DMA-BUF Mapping Warning" section in the PipeWire docs.

[meocoder31099]

The issues with tiling and compression can be addressed by requesting PipeWire to provide a linear modifier for the DMA-BUF. Synchronization is also handled by invoking the DMA_BUF_IOCTL_SYNC ioctl before and after any CPU access to the buffer. However, the problem of accessing the DMA-BUF being extremely slow remains unresolved as I am not familiar with the graphics APIs necessary to handle this efficiently.

[MAlba124]

I'm not convinced this is the way to go about handling dmabufs for two reasons:

1. The current implementation should work (there may be bugs causing it to not work + the missing handling of RGBA and MemFd that you kindly fixed in this PR) because the video source node should never give dmabufs when no modifiers is set. The only portal implementation I've tested with that doesn't respect this was cosmic's. Our param_changed callback might not handle params correctly, I'll take a look at it.
2. scap's frame types only store data in Vec<u8>, so any dmabuf handling would basically just do the same that the portal would do for SHM.

[meocoder31099]

You are absolutely correct. My current implementation will work if you are using COSMIC DE, but it will not guarantee working in all cases due to factors beyond our control (notably, if the portal does not respect the requested parameters from scap)