BluRay drive support

[NeonMan]

Description

Provide a way to check if the drive supports read support for BluRay discs and write support for BDR/BDRE/BDXL

Background

I am using libcdio to get and list the capabilities of an optical drive and I got my hands on a BluRay reader / recorder, however the enums defined on the API only include up to DVD media, making it inconvenient to test for BluRay capabilities, forcing me to rely on raw MMC commands to do it.

Priority

Tests

cdio_drive_read_cap_t and cdio_drive_write_cap_t must define values for BluRay media.

device.getDriveCap(i_read_cap, i_write_cap, i_misc_cap); must return the adequate values when a BLuRay drive is queried.

[rocky]

@NeonMan are you up for making a PR?

[NeonMan]

I'm extending the base class with the commands I'm using. If I end up using libcdio over libsgutils I may ask to merge them.

Edit: libcdio is a hard dependency in any case since I'm using its libudf so even if I use libsg, porting it to libcdio should be easy.

[rocky]

Ok. Thanks for the information.

[NeonMan]

I have found the only reliable way to communicate with a BD drive is using the SG_IO interface instead of the CDROM_SEND_PACKET. I haven't read much of the libcdio code so I don't know if the SG_IO interface is even supported but I tried with a simple test that ought to force SG_IO by passing the /dev/sgX dev instead of /dev/srX and it is ignoring it.

#include <cdio/cdio.h>
#include <cdio/logging.h>
#include <stdio.h>
#include <assert.h>

#define BD_SG_PATH "/dev/sg2"

int main(){
  uint8_t buf[64];
  cdio_loglevel_default = CDIO_LOG_DEBUG;
  CdIo_t *p_cdio = cdio_open(BD_SG_PATH, DRIVER_DEVICE);
  assert(p_cdio);

  //HW info
  {
    puts("--- HW Info  -----------------------------------------------------");
    cdio_hwinfo_t hwinfo;
    bool status = cdio_get_hwinfo(p_cdio, &hwinfo);
    assert(status);
    printf("%s %s %s\n", hwinfo.psz_vendor, hwinfo.psz_model, hwinfo.psz_revision);
  }
  cdio_destroy(p_cdio);
  return 0;
}

Build with cc -lcdio test.c The result is that it uses the old CDROM_SEND_PACKET interface:

--DEBUG: Trying driver AIX
--DEBUG: Trying driver FreeBSD
--DEBUG: Trying driver NetBSD
--DEBUG: Trying driver GNU/Linux
   INFO: found driver GNU/Linux
--- HW Info  -----------------------------------------------------
   INFO: ioctl CDROM_SEND_PACKET for command INQUIRY (0x12) failed:
        Operation not permitted
a.out: sg-io.c:19: main: Assertion `status' failed.

strace also reflects libcdio using the CDROM_SEND_PACKET interface instead of the SG_IO. Development is now relying on libsgutils but if the effort to port to libcdio is manageable it could be done.

Is it possible (or even implemented) to force the use of SG_IO on libcdio?

[rocky]

The way this kind of thing has been handled is add an "access_mode" provided by cdio_open_am

(Links to the doxygen doc are borked right now or I'd give a link to that.)

[NeonMan]

I'm slowly testing BD related functionality using the existing libcdio examples, starting with the read-disc-struct sample program. I will be pushing code to my local fork of the repository but I do have some style and formatting questions.

Edit: Im doing changes on my repo, getting things to work on a the drives that are not stalling.

[rocky]

I'm slowly testing BD related functionality using the existing libcdio examples, starting with the read-disc-struct sample program. I will be pushing code to my local fork of the repository but I do have some style and formatting questions.

Edit: Im doing changes on my repo, getting things to work on a the drives that are not stalling.

Ok. Great!

https://github.com/libcdio/libcdio/blob/master/.editorconfig notes what we have in the way of C formatting so far. And as noticed, we use Doxygen.

It has been suggested that we use a pretty-printer like clang-format . That's a possibility.

[tomty89]

Btw your test doesn't "force SG_IO interface (as in, ioctl)". If you call libcdio APIs and (if) they leverages the CDROM_SEND_PACKET ioctl (anyway), passing a scsi generic device (/dev/sgN) is not going to change that. It only changes the kernel driver (sr or sg) that receives / handles the ioctl.

In fact, the "core" of the two ioctls are the same (at least in recent / modern kernel versions):
https://elixir.bootlin.com/linux/v7.1.1/source/drivers/scsi/scsi_ioctl.c#L836
https://elixir.bootlin.com/linux/v7.1.1/source/drivers/scsi/scsi_ioctl.c#L860

I have no idea what exactly you are trying to achieve (or what you mean by "unreliable"), but AFAIK, other than some special / "low level" operation (as in, "instructions" involved during firmware flashing or maybe "microcode update" from e.g. MakeMKV for "LibreDrive"), I'm not aware that leveraging the scsi generic driver is necessary. Also, not even something like libaacs makes use of the SG_IO ioctl.

a way to check if the drive supports read support for BluRay discs and write support for BDR/BDRE/BDXL

Pretty sure you don't need the scsi generic driver for that, although I can't say for sure the same for the SG_IO ioctl. (Because when I try to run BDRFlash, a Pioneer drive flashing program, through wine, I need to set up "dosdevice / drive letter" pointing to the scsi generic device instead only for the actual flashing part. It can query the read/write caps of a drive through one pointing to the /dev/srN just fine.)

(To state the obvious, generally speaking the SG_IO ioctl works with both /dev/srN and /dev/sgN, AFAIK. It's just that one may not accept what you instruct through the ioctl while the other one will.)

P.S. btw this is the part that decides which ioctl would be used: https://github.com/libcdio/libcdio/blob/2.3.0/lib/driver/gnu_linux.c#L1287

Basically if you want to give libcdio an alternative, you would need to add an alternative of run_mmc_cmd_linux and make cdio_open_am_linux "register" that to run_mmc_cmd instead when e.g. an argument (some "access mode" mentioned above, maybe?) is passed or so: https://github.com/libcdio/libcdio/blob/2.3.0/lib/driver/gnu_linux.c#L1741

(btw _read_mode2_sector_linux and _read_mode2_sectors_linux make run_mmc_cmd_linux call...)

[NeonMan]

For what I discovered after starting writing code to talk with the drive, it seems the BDXL capable MT1959 drive is the only one giving me strange delays and behaviours, whereas a regular Pioneer BluRay drive is working as expected with both /dev/srX and /dev/sgX so I am leaning towards that particular drive having an excessive amount of "quirks" to it. All the reliability issues I encountered disappear with any other drive.

Re. Giving libcdio an alternate backend, that could be done, and it would make strace debug far easier, but as of now, im confortable developing on the "not quirky" drives and consider working deeper on my quirky drive later.