text:
Huge overhead on devcloud linked to dpctl calls

Version: numba_0.20.0dev3 and main
The three following dpctl calls 1 2 3 have huge wall time on edge devcloud (measured ranging from 10 to 30ms each call by py-spy, see speedscope report):
On the devcloud this add about 80 seconds to the k-means benchmark (for an expected 10 seconds).
I didn't see the issue on a local machine, but maybe the remaining small overhead that we reported comes from there.
@oleksandr-pavlyk not sure if this should be considered as an unreasonable use in numba_dpex (those calls should be expected to be that long and cached ?) or a bug in dpctl.
I've experimenting with caching the values and can confirm that caching those 3 calls completely remove the overhead.
Regarding the scope of the cache, I'll check if a hotfix that consists in storing those value in a WeakKeyDictionary where keys are val, and usm_mem, and wrapping SyclDevice(device) call in a lru_cache, is enough. (if so, will monkey-patch in sklearn_numba_dpex in the meantime).

To avoid confusion, the .svg file extension of the py-spy report file should be a .json extension. The .svg extension only make sense when py-spy is used to generate a flamegraph report as an SVG file instead of a json speedscope trace.

By zooming in the report, it seems that the overhead seems to come from the repeated calls to typeof_usm_ndarray:

but I cannot see the calls to dpctl.SyclDevice(device).

@ogrisel @fcharras could you please verify if https://github.com/IntelPython/numba-dpex/pull/946 fixes the issue?

Unfortunately, it doesn't fix. Looking at the PR it doesn't seem to change the instructions that lead to the time consuming steps in the OP (that are, dpctl.SyclDevice(device) and *.sycl_device.filter_string).

The workaround I've posted yesterday doesn't work either.

The dpctl.SyclDevice calls sycl::device constructor, which scores each available device and selects the one with the highest score.  SyclDevice.filter_string calls sycl::get_devices() and searches for the given device in that list.
Construction of SYCL devices may thus be expensive, as RT must talk to the hardware. numba-dpex should not be constructing the device, but rather should capture it from the instance of usm_ndarray that it is inferring the type from. This is forthcoming, but I do not the ETA.
This suggests that using SYCL_DEVICE_FILTER to limit the number of devices discoverable by RT should improve the timing.
Use sycl-ls to determine the appropriate value to set the environment variable to. For example: with SYCL_DEVICE_FILTER=level_zero:gpu:0 the runtime would only discover one level-zero GPU device.

@oleksandr-pavlyk
You are correct. We should extract device from usm_ndarray instead of creation of new one from filter_string.
But we still have to get *.filter_string since it is part of type signature. And getting filter_string is slow

I would argue that the need to store filter_string as part of type signature would be rendered unnecessary once boxing/unboxing of dpctl.SyclQueue is implemented.

@oleksandr-pavlyk
It doesn't matter if it is part of array type signature or queue type signature.
Device must be part of signature. We not just need to get queue. We need to know for which device we are compiling/calling function. The most human friendly form of adding it to type signature is to use filter_string. Alternatives are: device name, python object id, something else?

I've fixed the monkey-patching workaround given in a previous comment. This should work https://github.com/soda-inria/sklearn-numba-dpex/blob/e040e78d2a5492d7b7b0ec79c2576f0df15cb9db/sklearn_numba_dpex/patches/load_numba_dpex.py#L44

This even also (almost?) entirely fixes the remaining small overhead that we also noticed even on iGPUs on laptops after the caching overhaul. (pointed out at in https://github.com/IntelPython/numba-dpex/issues/886#issuecomment-1415981746)
So, this issue is exacerbated on the intel edge devcloud, but also noticeable on more ordinary hardware.

I would argue that the need to store filter_string as part of type signature would be rendered unnecessary once boxing/unboxing of dpctl.SyclQueue is implemented.

Absolutely. #930
Using the filter string for compute follows data and having it part of any type signature (DpnpNdArray or SyclQueue) is a no go. I only did it as a stop gap under time pressure.

We need to know for which device we are compiling/calling function.

Sure, but that has nothing to do with adding it to any type signature. Moreover, it is conceivable that advanced programmers will target sub-devices and have much finer gain control. For such cases, a filter string is not supported by SYCL.

The most human friendly form of adding it to type signature is to use filter_string

I agree, but given the performance overhead of generating a filter string it is not possible. We can perhaps add backend and device type as string attributes for ease of reading typemaps and such. It is the generation of device number that kills performance.

@diptorupd

I agree, but given the performance overhead of generating a filter string it is not possible.

I really don't see any problem in caching filter string for the device. You need to generate it only once for the created device.

FYI, I have added caching for filter_string property in https://github.com/IntelPython/dpctl/pull/1127

@oleksandr-pavlyk this is half of the fix for this issue I think ? The remaining issue is that since the cache key is a device instance, the cache is not shared for distinct arrays or queues. Would that be possible that all arrays share the same device instance (i.e having id(array.sycl_device) == id(dpctl.SyclDevice(array.device.filter_string))) for all arrays) without adding any overhead to the array.sycl_device call ? I was trying to look into monkey patching my way to that from what is exposed to the python interpreter byt I'm not sure it's possible now.

@fcharras Could you please try https://github.com/IntelPython/numba-dpex/pull/946 again? I've updated it according to your comment and I think with https://github.com/IntelPython/dpctl/pull/1127 it should solve the problem. I'm not sure if https://github.com/IntelPython/dpctl/pull/1127 is already on dppy/label/dev channel already or not.

I'll look more into that today and reach back.

authors: AlexanderKalistratov diptorupd fcharras ogrisel oleksandr-pavlyk

repo: IntelPython/numba-dpex


text:
Move coverage.py configs into pyproject.toml

We do not need a separate config file for coverage.py and the config options can be included inside pyproject.toml.

Merging as coverage generation worked as expected and no other code was touched.

source: gharchive/pull-request

repo: IntelPython/numba-dppy

license_type: permissive

license_source: github-api


text:
Announcement: Introducing the RealSense D457 GMSL/FAKRA stereo camera

Hi everyone,
Intel have introduced a new member of the RealSense stereo camera family called the D457.  It is based around the D450 depth module and the new Vision Processor D4 V5.
https://www.intelrealsense.com/depth-camera-d457/
https://www.intel.com/content/www/us/en/newsroom/news/new-realsense-depth-camera-d457.html

Its listing in the official RealSense Store can be found here:
https://store.intelrealsense.com/buy-intel-realsense-depth-camera-d457.html
To quote the store page:
"The Intel® RealSense™ Depth Camera D457 is our first GMSL/FAKRA high bandwidth stereo camera.  The D457 has an IP65 grade enclosure protecting it from dust ingress and projected water.  D457 has an on-board Maxim serializer chip.  A Maxim de-serializer is needed at host side to decode the streams".

Connect Tech provide support for D457 with their hardware products.
https://connecttech.com/connect-tech-offers-built-in-support-on-the-newly-announced-intel-gmsl-realsense-depth-camera-d457/

The RealSense Store retails an 8-pack of the D450 camera module and Vision Processor D4 V5 here:
https://store.intelrealsense.com/intelr-realsensetm-depth-module-d450-vision-processor-d4-board-v5-gmsl-fakra-8-pack.html

The dedicated data sheet document for the D457 can be downloaded here:
https://dev.intelrealsense.com/docs/intel-realsense-d400-series-product-family-datasheet
The official Intel CAD file for the D457 is here:
https://dev.intelrealsense.com/docs/stereo-depth-camera-d400#cad-files

How long is the coax cable that comes with the camera?
How much is its bend radius?

Thanks very much @Mat198 for your questions about the D457.  I have submitted them to my Intel RealSense colleagues to obtain the requested information.

Hi @Mat198   My Intel RealSense colleagues have provided the following D457 information.

The Fakra cable in the D457 box has a length of 1000 mm +/- 10

According to RG174 coax cable spec, the minimum radius is 9.9 mm.

Users can obtain a longer cable from the market.  It is recommended to use “LEONI Dacar 302” for a 10 ~15 m long cable.  An Intel RealSense colleague has tried RG174 cable on D457.  The maximum length is 11 m, but Dacar 302 can reach 15 m.

Thanks for your fast reply!
Does the GMSL interface need a different implementation, or it's ready to plug and play in this Syslogic computer?
https://www.syslogic.ai/jetson-agx-xavier/rugged-computer-rpc-rml-a3-e2
I saw ConnectTech products, but I'm aiming for an outdoor agriculture application that requires an IP rate of at least 65. https://connecttech.com/connect-tech-offers-built-in-support-on-the-newly-announced-intel-gmsl-realsense-depth-camera-d457/

A seperate Maxim de-serializer is needed at host side to decode the streams.  For users who wish to perform tests with the D457, the Connect Tech product is recommended as no de-serializer is needed in a Connect Tech / D457 setup.
The Intel RealSense sales team can be contacted regarding the de-serializer component.  A contact form for doing so is at the link below.
https://www.intelrealsense.com/talk-to-sales/

Understood. Thanks!

do you supply interface / adapter to connect it to nvidia AGX devkit somehow?

Hi @AndreV84  If you have obtained a de-serializer to decode the D457's streams at host-side then information about how to obtain the reference driver package for AGX Xavier can be found at https://github.com/IntelRealSense/librealsense/issues/11010#issuecomment-1330218867
In regards to cabling a 1 m FAKRA cable is supplied with the D457, as described at https://github.com/IntelRealSense/librealsense/issues/10984#issuecomment-1292320808

Hi @MartyG-RealSense
Thank you for following up!
However, the default  Jetson AGX devkit doesn't have the GSML port for the cabling. Could you extend on how to connect the camera to the default nvidia Jetson AGX devkit hardware, please? Are there any particular cable+ adapter things or how else it could be connected?

My understanding is that the cabling connects to the de-serializer board, like the one at the link below that a RealSense user at https://github.com/IntelRealSense/librealsense/issues/11010#issuecomment-1306030505 chose for their D457.
https://www.leopardimaging.com/product/accessories/adapters-carrier-boards/li-gmsl2-ipx-deser/
In the data sheet document for the D457, it states "GMSL is based on SerDes technology, meaning using a
serializer on the transmitter side and a de-serializer on the receiver side".

so for the camera connection we nee dto procure this board [ which is out of stock]
https://www.leopardimaging.com/product/accessories/adapters-carrier-boards/li-gmsl2-ipx-deser/ ?
are there any other boards we could buy for nvidia Jetson AGX devkit default implementation?

For the initial testing stage of a D457 project, Intel recommend using Connect Tech hardware so that purchasing a separate de-serializer is not required as de-serialization is built into the Connect Tech hardware.
https://connecttech.com/connect-tech-offers-built-in-support-on-the-newly-announced-intel-gmsl-realsense-depth-camera-d457/
If you would prefer to proceed directly to using a separate de-serializer component then it can be obtained through the Intel RealSense sales team, as described at https://github.com/IntelRealSense/librealsense/issues/10984#issuecomment-1292382772
Intel's de-serializer board can be plug onto the AGX Xavier board directly.  The D457 connects to the FAKRA connector on this board through a GMSL cable.

I would not name further de-serializer products at present without confirmation that they are able to function with the D457.  The RealSense user who purchased the LI-GMSL2-IPX-DESER product stated though that it contained MAX9296A technology, which should narrow down research for compatible de-serializer products.  For example, you could google for maxim deserializer "MAX9296A" (including the quotation marks so that relevant products are included in the search results).
A googling for the LI-GMSL2-IPX-DESER product that is out of stock at the link above is out of stock at other suppliers found in the search results too at the time of writing this.  One of the suppliers had a useful PDF brochure about it though that I have linked to below.
De-serializer.pdf

@MartyG-RealSense
Do we order a de serializer from intel realsense  somehow directly through sales easily?
or  we should look to order elsewhere e.g. from Leopard imaging?
The latter [LI] listed these:
We have below adapter boards and cable which can connect GMSL2 cameras to Jetson AGX Xavier, but I am sure if this deserializer adapter (with MAX9296) is compatible with Intel d457 camera.

LI-GMSL2-IPX-DESER
FAW-1233-03 cable
BLI-JXAV-MIPI-ADPT-4CAM```

But if Intel realsense can supply sale of de serializer it maybe even better option?

Also are there adapters for Jetson NX devkits by nvidia?

Contacting Intel sales regarding their de-serializer product that can plug directly onto AGX Xavier would be the safest option, especially in regard to your question of how to interface the de-serializer with the AGX board.
Intel's guidance is to use a Maxim de-serializer rather than a specific model of Maxim de-serializer, suggesting that if the de-serializer supports GMSL then it should be able to work.
My Intel RealSense colleagues confirmed with me that because D457 uses the GMSL protocol, any GMSL cable can work with it.

@MartyG-RealSense
Thank you for following up
I think I have filled the contact with sales form
Maybe they will follow up sometime in the future to reach back to me regarding the procurement of the de serializer. Does it take many days to get the contact from sales?

Bearing in mind that it is December 23 at the time of writing this, if you have not had a response in a couple of weeks then let me know and I will follow it up.

@MartyG-RealSense
Will these CSI-> GSML adapters provided by Intel or LI work with Nvidia Jetson Orin devkit by Nvidia? There is no such support for NX devits, right? But there is support for AGX. How about Orin Devkits?

The D457's Jetson reference driver support is designed to work with a de-serializer on AGX Xavier at this time.

Hi!
Is there any documentation for bringup? I have a Rudi-AGX and D457 cameras on my desk but realsense-viewer (v2.53.1) doesn't find them with their Jetpack & BSP 4.6.1 installed (4.6.1 was recommended by ConnectTech). I installed the base-image, do I maybe need to select any of their AR** or IMX 390 images? A USB3 D450 works fine btw with USB 3.2 connection.
Looking forward to any hints how to get them up and running...
Thanks!

Hi @jast1982  I will discuss your issue with my Intel RealSense colleagues.  Thanks very much for your patience!

Hi again @jast1982 My colleagues advised that first, you need to use the latest RealSense Viewer version.  I believe that you are already doing this as you are using SDK version 2.531.
Secondly, you need to obtain the D457 driver from Connect Tech.  Intel cannot help with this and you need to contact Connect Tech directly.

@MartyG-RealSense
Could you confirm if we ordering these three units for jetson AGX devkit will be able to use it for d457 connection? Thanks
LI-GMSL2-IPX-DESER
FAW-1233-03 cable
LI-JXAV-MIPI-ADPT-4CAM

@MartyG-RealSense
is it the deser board from intel?
https://store.intelrealsense.com/buy-intel-realsense-des457.html

The de-serializer board on the store link is the Intel one, though I would recommend contacting the Intel RealSense sales team to confirm pricing.  As mentioned above at https://github.com/IntelRealSense/librealsense/issues/10984#issuecomment-1364041699 - please allow another week for a response to your submitted query and I will follow it up for you if you have not received a response after that.  Thanks very much for your patience!
In regard to the components list, it was confirmed by my Intel RealSense support colleagues at https://github.com/IntelRealSense/librealsense/issues/11010#issuecomment-1306169640 that LI-GMSL2-IPX-DESER could be used with D457.
in regard to a cable, my colleagues recommended at https://github.com/IntelRealSense/librealsense/issues/10984#issuecomment-1292320808 using a LEONI Dacar 302 cable or a cable that is compliant with RG174.
The D457 camera should connect onto the de-serializer board.   If using Intel's de-serializer board then it should attach directly onto the AGX Xavier board.

Hi again @jast1982 My colleagues advised that first, you need to use the latest RealSense Viewer version. I believe that you are already doing this as you are using SDK version 2.531.
Secondly, you need to obtain the D457 driver from Connect Tech. Intel unfortunately cannot help with this and you need to contact Connect Tech directly.

Hi!
So, I was able to progress somewhat: Downloading the Realsense specific BSP from here https://connecttech.com/supported-cameras/ installing it according to the normal instructions and afterwards adding this line to /boot/extlinux/extlinux.conf:
FDT /boot/tegra194-agx-cti-AGX104-INTEL.dtb
enabled at least two out of my 4 connected realsense cameras on my system. I can see /dev/video0 to 11 and /dev/video2 and /dev/video8 play a video stream in VLC. Unfortunately the realsense-viewer outputs this:
29/12 10:34:54,968 INFO [548026171408] (context.cpp:382) Found 2 RealSense devices (mask 0xff)  29/12 10:34:55,251 INFO [548026171408] (rs.cpp:2701) Framebuffer size changed to 2688 x 756  29/12 10:34:55,252 INFO [548026171408] (rs.cpp:2701) Scale Factor is now 1  29/12 10:34:55,350 ERROR [547922886432] (librealsense-exception.h:52) xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument  29/12 10:34:55,356 WARNING [547922886432] (rs.cpp:310) null pointer passed for argument "device"  29/12 10:34:55,356 WARNING [547922886432] (rs.cpp:2704) Couldn't refresh devices - xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument
(V2.53.1, tried as user and with sudo)
Any ideas?

Hi @jast1982  As it is a xioctl error, it would indicate to me that there is a kernel conflict.  You could try building the SDK from source code with CMake with the RSUSB backend installation method to confirm whether or not this is the cause, as RSUSB bypasses the kernel and so is not dependent on Linux versions or kernel versions and does not require kernel patching.  RSUSB is not ideally suited to multiple cameras however, as a kernel-patched build works better with multicam.

@MartyG-RealSense That was my hope as well. Already compiling...

@MartyG-RealSense
It appears that the design presumes that LI deser is connected to the 4x cameras adapter
It doesn't appear that it can be connected directly to Jetson AGX, can it?
http://www.leopardimaging.com/uploads/LI-IMX390-GMSL2-XAVIER-xxxH_datasheet.pdf

@MartyG-RealSense  from LI regarding the purpose
The LI-JXAV-MIPI-ADPT-4CAM is a MIPI adapter which can connect GMSL2 camera and LI-GMSL2-IPX-DESER to the Jetson AGX.
Please make sure your d457 camera includes a GMSL2 interface (MAX9295). You may also need to build the Jetson driver for this camera kit.

@AndreV84  If you have an Intel NDA agreement then I recommend submitting a Zendesk support ticket to Intel for these technical questions about sourcing and attaching together components for use with D457.  Alternatively, if you intend to use components that are all made by LI then LI are likely to be able to assist, like with their response above.

@MartyG-RealSense
As far as I understand LI can not confirm that their solution works with d457 specifically as they did not do such testing specifically. But they say it compatible with the chip.
Could you extend on how to get through NDS step to Zendesk ticket creation, please?
community.intel.com/t5/Items-with-no-label/Multiple-Camera-Positions-Calibration/m-p/1443270#M17774

@MartyG-RealSense
Could you confirm that
" Intel D457 camera includes GMSL2 serializer (MAX9295)." ?
Thanks

@AndreV84  I will make enquires to my  RealSense colleagues about your question.  Thanks very much for your patience.

@MartyG-RealSense
I signed for Zendesk account
could you extend if Suite or Support type of subscription is required to create ticket to intel from zendesk account? Thanks

I have referred your latest enquiry to my colleagues.

@MartyG-RealSense
Thank you for following up
I did not hear back from realsense sales pertaining the intel de serializer ordering procedure or regarding price confirmation; is the listed at backorder page at librealsense price valid for the de serializer? Thanks

@AndreV84  Please send me an email at martyx.grover@intel.com so that I have your email contact to pass to my Intel RealSense colleagues.

@MartyG-RealSense on Jetson AGX devkit with intel dse serializer, whoch Jetson OS supported? the latest Jetpack 5.x? or only 4.x? Thanks

JetPack 5.0.2 support has only just been introduced into the RealSense SDK in its development branch and will therefore be included in the next SDK release (likely numbered 2.54.0).  At the time of writing this, 2.53.1 supports JetPack 4.6, though RealSense users have already been able to unofficially use JetPack 5 successfully with the SDK (though with IMU problems).
https://github.com/IntelRealSense/librealsense/tree/development

nvidia already released Jetpack 5.1
@MartyG-RealSense isn't it supported in the development branch of sdk? Thanks

SDK support of JetPack is not synchronized with new JetPack releases and support for specific JetPack versions is added over time.

Looks like it is very challenging to work with the GMSL/FAKRA interface.
Someone in this thread owns and have used the RealSense D457? would you please confirm that the USB port cannot be used for development purposes (or like the D455)?

Looks like it is very challenging to work with the GMSL/FAKRA interface.
Someone in this thread owns and have used the RealSense D457? would you please confirm that the USB port cannot be used for development purposes (or like the D455)?

Unfortunately my setup (ConnectTech Rudi + 1-6 Realsenses) still doesn't work due to an init issue with the cameras. Also ConnectTech doesn't seem to have a clue. Does anyone outside of Intel has a working setup?

I have this issue https://github.com/IntelRealSense/librealsense/issues/10984#issuecomment-1367191641 and no idea how to fix it. I tried with master and mipi branch with the same results. Cameras are detected, but open in librealsense fails.

The Leopard Imaging de-serializer board that my Intel RealSense colleagues confirmed is able to be used with D457 is now listd as In Stock at the time of writing this.
https://www.leopardimaging.com/product/accessories/adapters-carrier-boards/li-gmsl2-ipx-deser/

@MartyG-RealSense
did your colleague used it directly with AGX devkit somehow or it necessarily required an extra 1 to 4 cam MIPI adapter by LI in order to run?

I assume that it was a general statement of compatibility based on the store description rather than it having been actually purchased and tested on specific hardware.

I assume that it was a general statement of compatibility based on the store description rather than it having been actually purchased and tested on specific hardware.

the problem is that my boss already ordered as I passed your prior post to them
The Leopard Imaging de-serializer board that my Intel RealSense colleagues confirmed is able to be used with D457 is now listed as In Stock at the time of writing this.
https://www.leopardimaging.com/product/accessories/adapters-carrier-boards/li-gmsl2-ipx-deser/
according to the manufacturer the other required adapter 4xcameras MIPI won't be in the stock until mid March

@AndreV84  Thanks for the information about the adapter.
Advice from my Intel RealSense colleagues at https://github.com/IntelRealSense/librealsense/issues/11010#issuecomment-1301807128 stated that the de-serializer MAX9296A (the Leopard Imaging product uses MAX9296) can be paired with the MAX9295A serializer  built inside the D457.  As the Leopard Imaging board contains the appropriate de-serializer component, this is likely the basis of confidence that it can work when paired with D457.

Hi everyone, I have received information from my Intel RealSense colleagues that it is fine to use the D457 only in USB mode and it has the same USB performance and the same feature-set as the D455, with the added IP65 protection.  So it is absolutely valid to purchase the D457 for the protection and use it as a USB camera instead of in GMSL / FAKRA mode.

How do I make D457 work in USB mode? Just plug-and-play? Realsense-viewer is not finding it, but it works with my D435. Any advice?

Hi @Mat198  Are you using librealsense SDK version 2.53.1 please as this will be required for use with D457.

The SDK Version is correct. I can find the D435 with lsusb, but it doesn't show D457. It doesn't work on windows and another ubuntu 20.04 PC. Is my D457 camera dead? :(

If the D457 is not detected on a USB connection then unplugging the micro-sized end of the USB from the cable, turning it around the opposite way and re-inserting it into the camera can cause the camera to be detected.

Tried both sides without success. :cry: Any other think I can do?

Is your camera firmware driver version 5.14.0.0 ?

I'm not sure. I never changed the firmware so it must be the factory default.

I will consult with my Intel RealSense colleagues.  Thanks very much for your patience.

I will be waiting for you response. Thank you for the fast replies!

Hi @Mat198  My colleagues informed me that to enable USB mode you need to set the mode switch to USB mode, as the D457's default is MIPI mode.  The switch is under a small cap on the camera.

It worked @MartyG-RealSense. Thank you very much! I couldn't find anything about this mode switch in the user manual. The word "switch" is not even mentioned a single time. The documentation only states the hardware sync connector behind that cover. I think the datasheet should have this info.

It's great to hear that the mode switch resolved your problem!
The switch is illustrated on a diagram of the camera in the D457 data sheet on page 65 of its current edition.

Indeed it's on the datasheet. Could be easier to find, the text is actually an image. Anyway, thank you!

@MartyG-RealSense
is Jetpack 5.1 supported? at MIPI 5.02 is listed as supported by default;
so will we be able to use the camera with the Intels adapter board on AGX Jetson with OS by Jetpack 5.1?

JetPack 5.0.2 support will be included in the next SDK version, likely numbered 2.54.0.
RealSense users of JetPack 5 have been able to use unsupported JetPack 5 versions successfully if they do not patch the kernel or they build the SDK in RSUSB backend mode.

@MartyG-RealSense when you are talking about patching the kernel are you reffering to patching like in https://github.com/IntelRealSense/librealsense/blob/master/doc/installation_jetson.md#building-from-source-using-rsusb-backend
or like in patching like in MIPI driver for jetson patching?
If we are to try on 5.1 Jetpack JEtson are we to try with e.g.
https://github.com/IntelRealSense/librealsense/blob/master/scripts/libuvc_installation.sh
or need still to patch the kernel for de serializer driver before applying or trying it?

I mean kernel patching like in installation_jetson.md.  The Jetson users who had success with JetPack 5 were not using D457.  Those users were of course also using USB instead of GMSL / FAKRA.
When the D457's mode switch is set to USB, it should behave like a D455 and so be able to skip patching the kernel.
I do not currently have information on the effect that not patching the kernel would have on the camera when using it with a de-serializer in its default MIPI mode.

~/realsense_mipi_platform_driver$ ./apply_patches_ext.sh ./Linux_for_tegra/source/public 5.1
Wrong JetPack version (5.1)! Only 5.0.2 and 4.6.1 supported.

How do I apply this patch to 5.1 version?

The MIPI driver does not have a branch for 5.1.  As you pointed out, the only 5-version supported is 5.0.2.

I recall that in SDK 2.50.0 a RealSense user added support for JetPack 4.6 via a PR at https://github.com/IntelRealSense/librealsense/pull/9855/commits/13094ea0b8cfb6955ce6e69d18138afc125f56aa by submitting an edit of patch-realsense-ubuntu-L4T.sh.  Perhaps you could create a custom 'forked' version of librealsense and make your own edit to patch-realsense-ubuntu-L4T.sh to support 5.1 if you need 5.1 support added immediately to the patch script.

@MartyG-RealSense
after patching 5.0.2 with MIPI driver
multiple /dev/video devices appeared but after building librealsense sdk MIPI branch somehow the player shows no any device
any ideas?
which command to use with which branch for geting gsml camera outputs on 5.0.2 after patching OS with MIPI driver for 5.0.2?

Hi @AndreV84  Has your D457's mode switch under the removable cap been moved from MIPI mode to USB mode since you bought the camera?  If it has then the switch should be moved back to its MIPI position.

Hi @MartyG-RealSense
I think the switch hasn't been switched at all so it should be the default position as it comes from sales. However I will check with remote team to confirm. Is there a particular branch of the sdk with particular cmake build sequence that you could suggest to be used to get the gsml working somehow? Is use of the mipi sdk branch with rsusb= ON correct for use with gsml?
which branch has to be used?

D457 should be used with a minimum of SDK 2.53.1 and firmware 5.14.0.0.
FORCE_RSUSB_BACKEND relates to USB.  The SDK should be kernel patched for use with MIPI, as described in the reference driver's instructions.
https://github.com/IntelRealSense/realsense_mipi_platform_driver

Hi @MartyG-RealSense
the mipi patch has been applied
it resulted in multiple /dev/video
the MIPI branch of sdk has built 54.0 usig cmake command above
How could I ceck or update firmware if the device is not detected in realsense viewer? how to know what firmware does it get shipped with?

SDK 2.54.0 is not properly released yet and is still on the development branch of the SDK (i.e it is an unfinished SDK whose development is still in progress).  At this time, 2.53.1 should be used as this is currently the latest public release of the SDK.
https://github.com/IntelRealSense/librealsense/releases/tag/v2.53.1
The firmware version cannot be checked if the camera is not detected.  My own D457 shipped with firmware 5.13.01.0, though the firmware will depend on when a particular camera unit was manufactured and mine is an early pre-production version.
When the mode switch is set to USB, the camera is detected as a D455 as the D457 has all the features, performance and characteristics of a D455 in that mode.

@MartyG-RealSense
folks won't be switching to usb mode as they need gsml working
I built this branch https://github.com/IntelRealSense/librealsense/tree/D4XX_MIPI that is 2.54 as I noticed
do you suggest to build 2.53.1 public release? which arguments to use for cmake to make sure gsml will work on Jetson?

Some RealSense users prefer conventional USB over GMSL and the need for a de-serializer, and desire an Intel-made RealSense camera that can work with USB like a D455 but also has IP65 protection.  The D457 appeals to customers with those needs.
Yes, I suggest building the 2.53.1 public release.
There is not specific guidance for installing the SDK for GMSL, simply 'install 2.53.1' (presumably with Jetson-compatible instructions for those who are using Jetson).

@MartyG-RealSense
Should it reflect gsml camera?
realsense viewer doesn't show anything either but warning about missed udev rules

2.53.1 was built with these

how could we get the camera detected?

I would suggest setting DFORCE_RSUSB_BACKEND to Off.
Network Device is a valid instruction in 2.53.1, although network device is removed from the SDK in the next upcoming version as it was an experimental proof of concept rather than an official, validated Intel feature.
The MIPI reference driver is designed for use with Intel's own de-serializer board and with AGX Xavier and the driver should be ported by the customer if using it with a non-Intel de-serializer.  Intel are unable to provide assistance with this porting process, unfortunately.

we are using intel de serializer board
with external 12 power
with 5.0.2 OS  was pointed out by intel in MIPI driver instructions

Have your colleagues correctly plugged the Intel de-serializer board onto the AGX Xavier board and attached the D457 camera to the de-serializer with the 1000 mm official GMSL cable supplied with the camera?

@MartyG-RealSense
from devs
if we need to power the camera via the usb line
Or if the Gmsl cable provides power

after rebuilding with rsusb realsense seems detected the camera

The D457 was designed primarily for use with a GMSL connection, with the USB connector intended for debugging purposes (though it can be used as a full D455-like camera on USB). So USB would not be the main means of powering the camera.

@MartyG-RealSense
firmware upgrade doesn't get through gsml connection
does it require usb cable?
how do we upgrade from 13 to 14?

In general for any RealSense camera, performing firmware updates through a short-length USB cable (preferably an official RealSense one) is recommendable.
If the camera can be detected in the RealSense Viewer then you can update to 5.14.0.0 in the Viewer.  I have performed the update on my own D457 today via USB in the Viewer.

feedback
the option to build the mipi patch on AGX natively could have been more convenient but it won't run if following intel steps on AGX as steps are for x86_64 that introduces extra step extra computer in the patching process that can be avoided if building/ applying the patch on AGX natively

here you may find a reference example to build natively
https://www.viziochron.com/xavier#h.p_aiRTN3O-uTrg

Thanks so much @AndreV84 for sharing the feedback and reference for setting up on AGX Xavier!

Hello @MartyG-RealSense,
I have the Rudy AGX Jetson Xavier from connect Tech . They provide a BSP to have the D4XX mipi driver which works well when looking at the dmesg logs. I want to use GMSL and I have an issue when building librealsense.
When building from the development branch (which seems to support the D457 and GMSL and L4T 32.7.1) and applying the patch at ./scripts/patch-realsense-ubuntu-L4T.sh and building with cmake .. -DBUILD_EXAMPLES=true -DCMAKE_BUILD_TYPE=release -DFORCE_RSUSB_BACKEND=false , rs-depth returns the following issue :
There are 1 connected RealSense devices.
rs_error was raised when calling rs2_create_device(info_list:0x55a65045d0, index:0):
    xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument

The BSP uses JetPack 4.6.1 and L4T version 32.7.1. What are the instruction to build from source librealsense in this case?

@lmuffang
did you try to build the mipi branch of librealsense sdk available from github?
4.6.1 seems less recent release than we tried with ordinary nvidia devkit though

I applied the patch as mentioned in the build instruction for Jetson devices here. However, not applying them does not make a difference for my issue. I guess I will skip this patch from now on, not doing it cloud also prevent some conflit with connect Tech's BSP I think.
And yes I also already tried the D4XX_MIPI branch with the same outcome.
Connect Tech provides support for the D457 GMSL camera and their instruction are to flash the BSP with JetPack 4.6.1. They also suggested the same branch as you did @AndreV84.
Should I try using the latest JetPack version from Nvidia SDK manager instead of 4.6.1 for flashing?
I just tried using a newer BSP connect Tech send me and it seems to work a bit better, I can get RGB, motion and infrared 1&2 using GMSL in realsense-viewer, but when I try to enable the depth stream, I have no frame received and I need to reset my device. (I built realsense from the branch D4XX_MIPI)
Here are my realsense-viewer logs when enabling one infrared only (which works) and then the depth stream only (which does not):
realsense-viewer.log

@lmuffang the patch https://github.com/IntelRealSense/librealsense/blob/master/doc/installation_jetson.md#building-from-source-using-native-backend  seems is not relevant for gmsl use case, but may be applicable for d455 mode of the camera [ usb connection] if you wish to use it as usb 455 camera instead of using it as d457 via gmsl.
However, if you try using sdkmanager  it won't suceed as you need rather to use provided by ConnectTech OS image that has their devicetree changes integrated. Sdkmanager is only good for default nvidia devkit carrier boards as it seems.
Moreover, you may try to build a latest Public release 2.53.1 m as @MartyG-RealSense advised [ not the development branch] to see if outcomes will be different with it. In our setup both 2.53.1 & MIPI branches worked if built without RSUSB backend.
Hope it helps

So I managed to get it working.
I had CUDA missing before and I did not think it was an issue. So I installed the Jetson components (not the OS) via the Nvidia SDK manager after flashing the ConnectTech OS image. Then I could build realsense with -DBUILD_WITH_CUDA=true on the D4XX_MIPI branch and it worked!
However, on the latest Public release v2.53.1, I could not get the depth stream working using GMSL, only the infrared and color streams worked in that case.
Thanks @AndreV84 for your help

@lmuffang  It's great to hear that you were successful  :)
@AndreV84  Thanks so much for your help!

@MartyG-RealSense
Could you list reference for flashing camera led indicator, please?
A remote colleague pointed out flashing of d457 was unsteady. I am trying to decypher flashing states so we could correspond it to the mode of flashing of the camera .
Thanks
Andrew

Hi @AndreV84  I do not have information on that subject.  Please submit a Zendesk ticket to Intel about that query.

@MartyG-RealSense
folks are asking to ask "what type of barrel jack [is] used for the Gmsl adapter?"

Hi @AndreV84  If you are asking about the long blue GMSL connector on the side of the D457 camera, page 22 of the D457 data sheet document states that there are 14 different layouts for GMSL / FAKRA connectors and the D457 one is a C-coding (blue) connector.

So I managed to make it work
I had CUDA missing before and I did not think it was an issue. So I installed the Jetson components (not the OS) via the Nvidia SDK manager after flashing the ConnectTech OS image. Then I could build realsense with -DBUILD_WITH_CUDA=true on the D4XX_MIPI branch and it worked!
However, on the latest Public release v2.53.1, I could not get the depth stream working using GMSL, only the infrared and color streams worked in that case.
Thanks @AndreV84 for your help

Hi!
I have the same hardware setup and tried again to get the real sense cameras up and running, but also with CUDA I was not successful. However I still use Jetpack 4.6.1 with the CTI-L4T package V 32.7.1 since there doesn't seem to be a correct CTI-L4T package for the newer BSP for Jetpack 5.1.
What combination did you use eventually? Were any other kernel patches required?
Regards,
Jan

So I managed to make it work
I had CUDA missing before and I did not think it was an issue. So I installed the Jetson components (not the OS) via the Nvidia SDK manager after flashing the ConnectTech OS image. Then I could build realsense with -DBUILD_WITH_CUDA=true on the D4XX_MIPI branch and it worked!
However, on the latest Public release v2.53.1, I could not get the depth stream working using GMSL, only the infrared and color streams worked in that case.
Thanks @AndreV84 for your help

Hi!
I have the same hardware setup and tried again to get the real sense cameras up and running, but also with CUDA I was not successful. However I still use Jetpack 4.6.1 with the CTI-L4T package V 32.7.1 since there doesn't seem to be a correct CTI-L4T package for the newer BSP for Jetpack 5.1.
What combination did you use eventually? Were any other kernel patches required?
Regards, Jan

Hi Jan,
After I flashed the BSP as you did, I installed the Jetpack SDK Components via the Nvidia SDK as mentioned here. Then I built realsense with CUDA on the D4XX_MIPI branch and it worked. I did not apply any kernel patches, I just cloned the repo and simply built it from source.

So I managed to make it work

I had CUDA missing before and I did not think it was an issue. So I installed the Jetson components (not the OS) via the Nvidia SDK manager after flashing the ConnectTech OS image. Then I could build realsense with -DBUILD_WITH_CUDA=true on the D4XX_MIPI branch and it worked!

However, on the latest Public release v2.53.1, I could not get the depth stream working using GMSL, only the infrared and color streams worked in that case.

Thanks @AndreV84 for your help

Hi!

I have the same hardware setup and tried again to get the real sense cameras up and running, but also with CUDA I was not successful. However I still use Jetpack 4.6.1 with the CTI-L4T package V 32.7.1 since there doesn't seem to be a correct CTI-L4T package for the newer BSP for Jetpack 5.1.

What combination did you use eventually? Were any other kernel patches required?

Regards, Jan

Hi Jan,
After I flashed the BSP as you did, I installed the Jetpack SDK Components via the Nvidia SDK as mentioned here. Then I built realsense with CUDA on the D4XX_MIPI branch and it worked. I did not apply any kernel patches, I just cloned the repo and simply built it from source.

Hi!
Thank you for your advise! And just to confirm: With OS you meant installing Jetpack 4.6.1 + their CTI-L4T V32.7.1 package from the CTI camera homepage, running their script and selecting the configuration for Rudi+Realsense, correct?
Regards,
Jan

@MartyG-RealSense is it likely that we can run Zed X using intels de serializer card on AGX?
plug in did not autosetup as it seems
could you remind the maxim de serializer model of the intel gmsl agx adapter?
zed lists support of 96712/9626 from LI

Hi @AndreV84  I am unable to provide advice about non-RealSense cameras.
A zoom-in of an image of the Intel deserializer from the RealSense Store listing shows that it is using Maxim 9296A like the LI product does.

So I managed to make it work

I had CUDA missing before and I did not think it was an issue. So I installed the Jetson components (not the OS) via the Nvidia SDK manager after flashing the ConnectTech OS image. Then I could build realsense with -DBUILD_WITH_CUDA=true on the D4XX_MIPI branch and it worked!

However, on the latest Public release v2.53.1, I could not get the depth stream working using GMSL, only the infrared and color streams worked in that case.

Thanks @AndreV84 for your help

Hi!

I have the same hardware setup and tried again to get the real sense cameras up and running, but also with CUDA I was not successful. However I still use Jetpack 4.6.1 with the CTI-L4T package V 32.7.1 since there doesn't seem to be a correct CTI-L4T package for the newer BSP for Jetpack 5.1.

What combination did you use eventually? Were any other kernel patches required?

Regards, Jan

Hi Jan,
After I flashed the BSP as you did, I installed the Jetpack SDK Components via the Nvidia SDK as mentioned here. Then I built realsense with CUDA on the D4XX_MIPI branch and it worked. I did not apply any kernel patches, I just cloned the repo and simply built it from source.

Hi!
Thank you for your advise! And just to confirm: With OS you meant installing Jetpack 4.6.1 + their CTI-L4T V32.7.1 package from the CTI camera homepage, running their script and selecting the configuration for Rudi+Realsense, correct?
Regards,
Jan

Hi!
I wasn't able to get the D457 to run until CTIs support suggest to try the tag https://github.com/IntelRealSense/librealsense/releases/tag/v2.50.40_MIPI_QS_RC2 which worked then right away with jetpack 4.6.1 and their BSP v32.7.1 from their camera homepage.
Even without CUDA btw.
Regards,
Jan

Thanks so much Jan for sharing the advice!

I had purchased the LI-GMSL2-IPX-DESER product from the Leopard Imaging.
https://www.leopardimaging.com/product/nvidia-jetson-cameras/nvidia_agx_xavier_gmsl2_camera_kits/li-imx390-gmsl2-xavier/li-imx390-gmsl2-xavier-120h/
And try developt Intel D457 on AGX Xavier.
My hardware environment are:
Nvidia Jetson AGX Xavier EVB * 1
Leopad LI-JXAV-MIPI-ADPT-4CAM board * 1
Leopad LI-GMSL2-IPX-DESER board * 1
Leopad FAW-1233-03 cable *1
Intel RealSense D457 camera * 1
GMSL FAKA cable * 1
May I use the realsense_mipi_platform_driver from Intel GitHub to develop  Intel D457 + LI-GMSL2-IPX-DESER on AGX Xavier?
https://github.com/IntelRealSense/realsense_mipi_platform_driver

Hi @sammychentw The RealSense MIPI driver for D457 is designed for AGX Xavier and Intel's own brand of deserializer. Whilst you can use your own choice of deserializer, to use the driver with your own hardware (a Leopard deserializer) you will need to port (convert) the MIPI driver for use on your equipment. Intel are unable to provide assistance with this porting process unfortunately.

May I confirm below Intel RealSense D4 GMSL De-serializer board could meet the RealSense MIPI driver for D457?
Intel® RealSense™ Vision Processor D4 GMSL/FAKRA De-serializer Board
https://store.intelrealsense.com/buy-intel-realsense-des457.html

The MIPI driver was designed for that specific Intel deserializer.   It is not available for purchase in single or small quantities though but rather for manufacturer-scale orders, so it is necessary to instead purchase a non-Intel deserializer and port the MIPI driver.
An alternative is to use the D457-compatible AGX Orin hardware product by the company Connect Tech, which has built-in support for D457 and does not require the purchase of a separate deserializer.
https://connecttech.com/connect-tech-offers-built-in-support-on-the-newly-announced-intel-gmsl-realsense-depth-camera-d457/

Does anyone have any info on the Leopard Imaging boards + AGX Orin gmsl/fakra setup? Seems like there should be drivers out there.

Hello. I just received my D457 camera and I can not get it working with USB Type C port.
When I connect with Type C the slush command shows no change. I have also tried it in windows 10 after installing latest SDK. Nothing in device manager. Your help is very much appreciated.

Hi @MhmRhm  To use the camera with a USB cable you need to move a physical switch sideways that is under a removable cap on top of the camera.  Information about this can be found at the link below.
https://support.intelrealsense.com/hc/en-us/community/posts/14840675121043/comments/14843232242835

@MartyG-RealSense
There again emerged some issue with d457 not detected;  at AGX nvidia devkit
Since I do not see how to troubleshoot it easily it was considered that unit will get reflashed;
The question is what is the current newest supported OS and what is the procedure for installing the driver if changed;
Thanks
AV

Hi @AndreV84  The newest supported OS at the time of writing this is Ubuntu 22.04, though support for the recent 24.04 Noble Numbat and ROS2 Jazzy is planned.
If you mean the D457's MIPI reference driver AGX Xavier, installation instructions can be found on the driver's page at the link below.
https://github.com/IntelRealSense/realsense_mipi_platform_driver

@MartyG-RealSense Thanks but what version of realsense sdk to build? the latest one? for gmsl

Yes, 2.55.1 supports D457 / MIPI, as described in the 2.55.1 release notes at the link below.  The notes recommend reinstalling the udev rules and the MIPI reference driver though.
https://github.com/IntelRealSense/librealsense/wiki/Release-Notes#release-2551

the problem is that while the github repo lists support os 5.1.2 Jetpack os
the release you pointed out to only could support of 5x the release 5.0.2
after installing mipi driver it got all like that:
ndre
8:20 PM
ipped.
[   70.435540] systemd[1]: Starting udev Kernel Device Manager...
[   70.436732] max9295 30-0040: max9295_write_reg:i2c write failed, 0x0 = 84
[   70.438661] max9295 30-0042: max9295_write_reg:i2c write failed, 0x10 = 21
[   70.438796] max9295 30-0042: max9295_setup_control: ERROR: ser device not found
[   70.438802] d4xx 30-001a: gmsl serializer setup failed
[   70.439418] d4xx 30-001a: ds5_serdes_setup gmsl serdes setup failed
[   70.453457] d4xx: probe of 30-001a failed with error -121
[   70.454459] systemd[1]: Started Journal Service.
[   70.458753] d4xx 33-001a: Probing driver for D45x
[   70.468979] d4xx 33-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.469355] d4xx 33-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.480755] d4xx 33-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.486885] d4xx 33-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.493316] d4xx 33-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.493673] d4xx 33-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.493700] d4xx 33-001a: ds5_probe(): cannot communicate with D4XX: -121 on addr: 0x1a
[   70.493940] d4xx: probe of 33-001a failed with error -121
[   70.493995] d4xx 34-001a: Probing driver for D45x
[   70.494764] d4xx 34-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.530152] d4xx 34-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.536197] d4xx 34-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.536578] d4xx 34-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.536918] d4xx 34-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.537282] d4xx 34-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.537288] d4xx 34-001a: ds5_probe(): cannot communicate with D4XX: -121 on addr: 0x1a
[   70.537508] d4xx: probe of 34-001a failed with error -121
[   70.574162] d4xx 35-001a: Probing driver for D45x
[   70.575039] d4xx 35-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.585328] d4xx 35-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.585699] d4xx 35-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.586213] d4xx 35-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.604094] d4xx 35-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.610565] d4xx 35-001a: ds5_read(): i2c read failed -121, 0x5020
[   70.610571] d4xx 35-001a: ds5_probe(): cannot communicate with D4XX: -121 on addr: 0x1a
[   70.610817] d4xx: probe of 35-001a failed with error -121
[   70.628948] nvmap_heap_init: nvmap_heap_init: created heap

It doesn't seem it worked? no /dev/video devices are present @MartyG-RealSense

does the sdk have to be built from sources or the apt installation should do with 2.55.1 ?

what does the red led indicate?

@AndreV84  I do not recognize the hardware in the image.  Can you provide information about what the component is, please?
SDK 2.55.1 introduces support for JetPack 6.0.  JetPack 5.0.2 is also supported.  Some Jetson users have built the SDK from source code and not applied the kernel patch script if they have not had an officially supported JetPack version.

@MartyG-RealSense isn't it the intel jetson agx gmsl board at the image?
is 5.1.2 Jetpack supported? by 2.55.1?

it blinks with green led during the boot process twice shortly; then pause then once again
then only red led radiates

https://store.intelrealsense.com/buy-intel-realsense-des457.html

@MartyG-RealSense

linux-image-5.10.120 with d457 won't work as it seems due to lack of driver integration or else
following up instructions won't work
https://github.com/IntelRealSense/realsense_mipi_platform_driver/issues/207

I will consult with my Intel RealSense colleagues about your issues with the official Intel deserializer board and let you know as soon as I have information.

@MartyG-RealSense Thank you for following up!
now it got green leds of that one radiates constantly then another blinks between red/green
is there

a way to read from camera without realsense sdk maybe ?

In GMSL mode it needs the MIPI reference driver.
The camera would likely work in USB mode as a D455 if you moved the mode switch in the casing to the USB position but that would not provide useful information about your GMSL problem, unfortunately.
The best place to seek support on this issue is likely to be the Zendesk support channel, which you have used before for previous D457 issues such as https://github.com/IntelRealSense/librealsense/issues/10560#issuecomment-1400689652

@MartyG-RealSense may I know what is the url for zendesk support ticketing system, please?

The claims for verification control have not been verified.
The code has been verified. You can now continue.

that is what I got logging in

I do not have information about submitting tickets to Zendesk.  From https://github.com/IntelRealSense/librealsense/issues/10560#issuecomment-1400689652 it sounds as though you have successfully contacted Intel's Zendesk channel in the past.

there was some w instruction at the url as it seems:
https://forums.intel.com/s/question/0D70P000006GkkASAS

somehow created request somewhere with zendesk realsense
thanks
(22669) request

That's great to hear!

@MartyG-RealSense is it correct to use this script to build the sdk from sources?
https://github.com/IntelRealSense/librealsense/blob/master/scripts/libuvc_installation.sh

@AndreV84  I do not recall this build script being previously used for a MIPI connection but the script has been updated to include a MIPI version of the udev device handling rules.
https://github.com/IntelRealSense/librealsense/blob/master/scripts/libuvc_installation.sh#L43

what are the power input characteristics requirements for the board? I see 12v-13.7v is written at the board; what Ampere does it expect o nthe input port?
@MartyG-RealSense

this component seems got llost even if it was present for gmsl card so are there specific power input requirements but for 12v-13.7v range?
@MartyG-RealSense

@AndreV84  There is not any publicly available technical information about the Intel deserializer board.  It will be necessary to enquire to Intel's Zendesk support channel for that information.

I asked them but there was no specific answer yet but a general reference to github repository
Is this error pointing out issue with gmsl board or with camera?
 max9295 30-0042: max9295_setup_control: ERROR: ser device not found

folks changed the power source after that the driver issue got resolved; 2.53 sdk also worked; now the only thing is to figure out how to buld the latest sdk

It's great to hear that you were completely successful  :)

folks are asking to check:"
exactly what size stand-off we need?
To secure it to the AGX unit?"
@MartyG-RealSense

@AndreV84  I will ask my colleagues about that question too.

@AndreV84  My colleagues advised that the stack space is 11 mm.  They added that there should have been 4 pieces of stand-off included in the Xavier carrier board package.  Did your package have these pieces, please?

thank you for following up!
folks pointed out "We didn’t get the standoffs"

Okay, I will follow up with my colleagues about the missing stand-offs.

@AndreV84  My colleagues advised that the package should include the following items as a kit:

Board
Power supply
GSML cable
Stand offs / screws in a small ziplock bag

Can you ask your team please if they received the board, power supply and GMSL cable and whether the stand-offs and screws were the only item missing.

Hello @MartyG-RealSense, the post mentions mostly ConnectTech's hardware. Do you have by chance a list of carrier boards that supports D457 GMSL, both hardware and software?

Hi @tonynajjar  There is not a list available, unfortunately.  The most compatible boards will be Nvidia Jetson AGX Xavier or Orin, as Intel's D457 MIPI driver has installation instructions for those specific boards at the link below.
https://github.com/IntelRealSense/realsense_mipi_platform_driver
The MIPI driver can be converted ("ported") for other boards but you need to perform this conversion yourself as Intel are unable to provide assistance for doing so.
If you are not using Connect Tech's product then you will also need to purchase an additional deserializer board.  Leopard Imaging's LI-GMSL2-IPX-DESER deserializer board is compatible with D457.
https://leopardimaging.com/product/accessories/adapters-carrier-boards/li-gmsl2-ipx-deser/
Other brands of deserializer board should also work though as long as they contain MAX9296A deserializer technology like the Leopard Imaging LI-GMSL2-IPX-DESER product does.

source: gharchive/issue

authors: AndreV84 MartyG-RealSense Mat198 MhmRhm jast1982 javier-recasens jrecasens lmuffang robotom sammychentw tonynajjar

repo: IntelRealSense/librealsense


text:
rs-server on Windows

Required Info

Camera Model
D435i

Operating System & Version
Win 10

Platform
PC

Issue Description
https://dev.intelrealsense.com/docs/open-source-ethernet-networking-for-intel-realsense-depth-cameras
I would like to apply the contents of this article to a solution I am currently designing.
However, this article seems to assume a Linux PC (Raspberry Pi 4) as the server machine, but I want to use Windows 10 for the server.
Is there any plan to make rs-server workable on Windows?
I built rs-server on Windows to try:

git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense\tools\rs-server
Open CMakeLists.txt and delete 'if(WIN32) message(...)'
mkdir build; cd build; cmake ..
Open rs-server.sln, add several path and build
I got a lot of link errors for live555

Do these link errors have anything to do with why rs-server is not supported on Windows?
Is there any possibility to build completely to the end without link errors on Windows?
Thank you.

Hi @terranas  rs-server currently can only be compiled on Linux.  I do not have information about the reason for this.
Would it be practical for you to set up your remote computer to be dual boot (both Windows and Linux installed on it) so that you can set up rs-server on the Linux OS and boot into Linux mode when running the computer as a remote server?
https://opensource.com/article/18/5/dual-boot-linux

Hi @terranas  Do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.

Sorry for the delay.
After that, I made some changes to the original code, and run successfully rs-server on Windows 10.
Thank you very much for releasing useful whitepaper.

That's excellent news @terranas that you were successful - thanks very much for the update   :)

Hi @terranas,
I am trying to build the rs-server on Windows 10 and it does not work for me, could you tell what changes you have made to make it work?
Best regards,
Julian

Hi @jbruno79
Please apply following patch to the tag v2.49.0.
Most important is linking ws2_32.lib. (I wonder why the development team didn't do this)
I hope it works :)
 tools/CMakeLists.txt           |  6 +--
 tools/rs-server/CMakeLists.txt | 83 ++++++++++++++++++----------------
 2 files changed, 46 insertions(+), 43 deletions(-)

diff --git a/tools/CMakeLists.txt b/tools/CMakeLists.txt
index b1b967af2..13f05a984 100644
--- a/tools/CMakeLists.txt
+++ b/tools/CMakeLists.txt
@@ -19,10 +19,8 @@ add_subdirectory(terminal)
 add_subdirectory(recorder)
 add_subdirectory(fw-update)

-if(NOT WIN32)
-    if(BUILD_NETWORK_DEVICE)
-        add_subdirectory(rs-server)
-    endif()
+if(BUILD_NETWORK_DEVICE)
+    add_subdirectory(rs-server)
 endif()
 endif()

diff --git a/tools/rs-server/CMakeLists.txt b/tools/rs-server/CMakeLists.txt
index 617a72379..bbb5a0be0 100644
--- a/tools/rs-server/CMakeLists.txt
+++ b/tools/rs-server/CMakeLists.txt
@@ -20,46 +20,51 @@ SET(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-pthread")

 set(LIVE ${CMAKE_BINARY_DIR}/third-party/live)

+file(GLOB LIVE_SOURCES LIST_DIRECTORIES false CONFIGURE_DEPENDS
+"../../src/ipDeviceCommon/*.c*"
+"${LIVE}/*.c*"
+"${LIVE}/groupsock/*.c*"
+"${LIVE}/BasicUsageEnvironment/*.c*"
+"${LIVE}/liveMedia/*.c*"
+"${LIVE}/UsageEnvironment/*.c*"
+)
+source_group("LIVE555" FILES ${LIVE_SOURCES})
+file(GLOB RS_SERVER_SOURCES LIST_DIRECTORIES false CONFIGURE_DEPENDS
+"*.c*"
+)
+list(APPEND RS_SERVER_SOURCES ${LIVE_SOURCES})
+list(REMOVE_ITEM RS_SERVER_SOURCES "${LIVE}/liveMedia/ADTSAudioStreamDiscreteFramer.cpp")
+if (${BUILD_SHARED_LIBS} AND ${BUILD_EASYLOGGINGPP})
+    list(APPEND RS_SERVER_SOURCES ../../third-party/easyloggingpp/src/easylogging++.cc)
+endif()
+add_executable(${PROJECT_NAME} ${RS_SERVER_SOURCES})
+add_definitions(-DELPP_NO_DEFAULT_LOG_FILE)
+
+include_directories(
+../../common
+../../src
+../../src/ipDeviceCommon
+../../include/librealsense2
+../../third-party/tclap/include
+../../third-party/easyloggingpp/src
+${LIVE}/groupsock/include
+${LIVE}/liveMedia/include
+${LIVE}/UsageEnvironment/include
+${LIVE}/BasicUsageEnvironment/include
+)
+
+set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11)
+
+set(DEPENDENCIES ${DEPENDENCIES} realsense2 Threads::Threads realsense2-compression ${ZLIB_LIBRARIES} ${JPEG_LIBRARIES})
+
 if(WIN32)
-  message(SEND_ERROR "rs-server supports Linux only")
-else()
-  file(GLOB RS_SERVER_SOURCES LIST_DIRECTORIES false CONFIGURE_DEPENDS
-    "*.c*"
-    "../../src/ipDeviceCommon/*.c*"
-    "${LIVE}/*.c*"
-    "${LIVE}/groupsock/*.c*"
-    "${LIVE}/BasicUsageEnvironment/*.c*"
-    "${LIVE}/liveMedia/*.c*"
-    "${LIVE}/UsageEnvironment/*.c*"
-  )
-  list(REMOVE_ITEM RS_SERVER_SOURCES "${LIVE}/liveMedia/ADTSAudioStreamDiscreteFramer.cpp")
-  add_executable(${PROJECT_NAME} ${RS_SERVER_SOURCES})
-  add_definitions(-DELPP_NO_DEFAULT_LOG_FILE)
-
-  include_directories(
-    ../../common
-    ../../src
-    ../../src/ipDeviceCommon
-    ../../include/librealsense2
-    ../../third-party/tclap/include
-    ../../third-party/easyloggingpp/src
-    ${LIVE}/groupsock/include
-    ${LIVE}/liveMedia/include
-    ${LIVE}/UsageEnvironment/include
-    ${LIVE}/BasicUsageEnvironment/include
-  )
-
-  set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11)
-
-  set(DEPENDENCIES ${DEPENDENCIES} realsense2 Threads::Threads realsense2-compression ${ZLIB_LIBRARIES} ${JPEG_LIBRARIES})
-
-  target_link_libraries(${PROJECT_NAME} ${DEPENDENCIES})
-
-  set_target_properties(${PROJECT_NAME} PROPERTIES FOLDER "Tools")
-
-  target_compile_definitions(${PROJECT_NAME} PUBLIC RESPONSE_BUFFER_SIZE=100000)
-
-  install(TARGETS ${PROJECT_NAME} RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
+	set(DEPENDENCIES ${DEPENDENCIES} ws2_32)
 endif()

+target_link_libraries(${PROJECT_NAME} ${DEPENDENCIES})
+
+set_target_properties(${PROJECT_NAME} PROPERTIES FOLDER "Tools")
+
+target_compile_definitions(${PROJECT_NAME} PUBLIC RESPONSE_BUFFER_SIZE=100000)

+install(TARGETS ${PROJECT_NAME} RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})

authors: MartyG-RealSense jbruno79 terranas


text:
rs-ar-basic: fix extrinsic pose to camera transformation

Found by user @JBBee: https://github.com/IntelRealSense/librealsense/issues/4883#issuecomment-535597865.

@radfordi Could you also update this comment:
// This is the pose of the fisheye sensor relative to the T265 coordinate system.

It should say the opposite:
// This is the pose of the T265 coordinate system relative to the fisheye sensor

Thanks @dorian3d.  I changed the variable name to replace the comment.  That way it makes the usage site clearer as well.

Thanks @radfordi. I forgot about the readme. Do you mind updating it too?


text:
Add entity API

PLEASE READ THE GUIDELINES BEFORE MAKING A CONTRIBUTION

Please check if the PR fulfills these requirements

[x] The commit message are well described
[ ] Docs have been added / updated (for features or maybe bugs which were noted). If not, please update the needed documentation here. This is not mandatory
[x] All changes have fully been tested

What kind of change does this PR introduce? (Bug fix, feature, ...)
Feature.

What is the current behavior? (You can also link to an open issue here)
Calling EnvironmentDetectorPeripheral.scanEntities() gives only a small amount of information on each entity. I felt like this could be used to a greater potential.

What is the new behavior (if this is a feature change)?
Instead of getting a table with a small amount of data when calling EnvironmentDetectorPeripheral.scanEntities(), UUIDs for entities are now the only thing that is returned. These can be used with the new entity API. For example, entity.getNBT(uuid) returns the NBT data of the entity with the given UUID.
The entity API itself can be disabled in config, as well as the individual functions within it that could be deemed exploitative on servers.
A PlayerDetectorPeripheral.getPlayerUUID(username) Lua function has also been added so that you can make use of the entity API when using a PlayerDetectorPeripheral.
I have also expanded the amount of entity information you get when calling LuaConverter.completeEntityToLua(entity). This function can be called via the entity API with entity.getData(uuid).

Does this PR introduce a breaking change? (What changes might users need to make in their scripts due to this PR?)
Yes, any calls to EnvironmentDetectorPeripheral.scanEntities() will need to use the entity API to get the data that it used to give you.
Calls to AutomataEntityHandPlugin.searchAnimals() now have position information in a table with the key relativePos. This was a side-effect of cleaning up LuaConverter.completeEntityToLua(entity) to not require an ItemStack to be passed to it.

Other information:
I can make a PR for the docs if this PR is to be merged.

Here's a script that I've been testing with: https://pastebin.com/uCH39VEm

Before I start reviewing
Since this adds a wider palette of features and due to the fact that this includes a breaking change, could you change the target branch to dev/0.8 so this features will be implemented to the new major version?

Done

Greetings
The build seems to fail, I am not sure if the issues came with the change of the target branch, but they are there
Could you fix them? I would also recommend running gradle check afterward to check for checkstyle rule violations.
You can either open the build log from teamcity by clicking on "Details" or you just could try to build it locally

My bad, it builds now

You still didn't fix the checkstyle violations
Either check the teamcity build log or run gradle check locally

Foremost, thanks for the PR and I really like your idea
I also discussed that internally with some collaborators, and we agree that switching to an LuaAPI based entity api is a great idea
The changes look good, but I didn't inspect them too deeply. I will take some time this week to review your changes and test them a bit for me

Would it have made more sense to implement this with peripheral methods instead of polluting the global namespace? You could return a userdata from the scan method, return all the information by default, or just add another method to the peripheral for looking up data by uuid

Would it have made more sense to implement this with peripheral methods instead of polluting the global namespace?

Originally I started with adding a getNBT(UUID) function to EnvironmentDetectorPeripheral, since I didnt want to put the huge NBT information in the small table returned by scanEntities, but if you think about it it makes no sense to have a getNBT function in EnvironmentDetectorPeripheral. Its either have a massive table returned or separate this into an Entity API which can have more fine-grained functions, so I opted for the later. It also isn't clear which functions in different peripherals return what entity data, but if you get a UUID from EnvironmentDetectorPeripheral.scanEntities and a UUID from PlayerDetectorPeripheral.getPlayerUUID, you know that Entity.getData(UUID) will return the same type of information for both entities.

You could return a userdata from the scan method

It was already the case before that some functions returned different entity data than others for no real reason. scanEntities only gave you like 10 fields per entity so it wasn't very useful, whereas searchAnimals gave you a lot of information, but still didn't include NBT data. It is easier to maintain and more consistent if this is all in one place.

return all the information by default

You could return all data, but there is a lot of information available now. It feels almost wrong to lump almost all information on the entity into one huge table. This would be NBT, almost all runtime data, and all persistent data. If you just need to get the positions of entities then this is all useless information.

or just add another method to the peripheral for looking up data by uuid

Something like getEntityData(UUID) wouldn't make sense in any one peripheral

After looking at some of my changes again though, I think it would make sense for AutomataEntityHandPlugin.searchAnimals and AutomataEntityTransferPlugin.getCapturedAnimal to both return UUIDs instead of completeEntityToLuaWithShearable.

Would it have made more sense to implement this with peripheral methods instead of polluting the global namespace? You could return a userdata from the scan method, return all the information by default, or just add another method to the peripheral for looking up data by uuid

I am currently discussing that a bit with some of the CC community in the CC discord. I know that additions to the global API are not welcome in the community. AP already does unconventional things that I want to eliminate in 0.8, and I'd hate to add more.

I am currently discussing that a bit with some of the CC community in the CC discord. I know that additions to the global API are not welcome in the community. AP already does unconventional things that I want to eliminate in 0.8, and I'd hate to add more.

Damn thats unfortunate, I wasn't aware of that. It's an issue of usability and code quality vs global pollution then. It's a shame that an entity API isn't available in CC itself

Another alternative is turning the Player Detector peripheral into an Entity Detector peripheral. All functionality of the entity API could be put in the Entity Detector. scanEntities could be removed from the Environment Detector and put into the Entity Detector.

I support that idea
Adding all the entity related features to one block would be the ideal compromise imo
you could also participate in the small dicussion in the #modmaking chat on the cc discord

One idea I like is to still add all the entity API functions to the environmental detector but to separate them a bit, put them into a table which you can retrieve using getEntityAPI.
This would be simpler than "adding the API to the global environment, but only when the peripheral is attached" imo
So maybe you want to go with that?

One idea I like is to still add all the entity API functions to the environmental detector but to separate them a bit, put them into a table which you can retrieve using getEntityAPI. This would be simpler than "adding the API to the global environment, but only when the peripheral is attached" imo
So maybe you want to go with that?
I will also convert this to a draft until we agree on a method

For the idea of turning the Player Detector into an Entity Detector:
Player Detector has four player-specific things: the playerClick, playerJoin, playerLeave events, and the getOnlinePlayers function. Everything else can be made to work for any entity (1 event and 10 functions). The getPlayers functions currently return the names of players, but could become getEntities and return entity UUIDs instead. The functions migrated from the EntityAPI like getName(UUID) or getNBT(UUID) would have checks within them to see if the entity is still within the range of the Entity Detector so that these can't be abused to get information about entities anywhere.
I think a getEntityAPI on the Environment Detector is a possibility, although you'd then have almost duplicate functions across peripherals (such as EnvironmentDetector.EntityAPI.getPos and PlayerDetector.getPlayerPos). An Entity Detector could replace all functions that get entity data in all other peripherals.

Merging the two peripherals is an interesting idea, but I don't really like it. Merging them would create one peripheral with maybe too many functions imo which wouldn't keep it simple
Developing the Player Detector and the Environment Detector separately would be my way to go. I would simply accept the duplicates, as there are apparently only 2 functions (getPlayerPos and getOnlinePlayers)
Keeping the player related functions (isPlayerInX... getPlayersInX...) and events to the player detector would make it simpler for the user imo to just have player related functions in one dedicated block while there would be the more advanced entity api in the Environment Detector

Sweet. I'm going away for a week but I'll work on that when I get back

Greetings @lonevox
Do you have any plans on continuing this?

Greetings @lonevox Do you have any plans on continuing this?

I took quite a hiatus from making my pack which is why I completely disappeared, sorry about that. I'll try getting the PR ready with the discussed changes within the next few days. I'll still be working on adding it to 1.20.1.

@SirEndii I'm having trouble exposing the EntityAPI class as a table through the EnvironmentDetectorPeripheral like you suggested. Here's what I assume would work, but isn't:
@LuaFunction(mainThread = true)
public final EntityAPI getEntityAPI() {
    return new EntityAPI();
}

It successfully returns a table, but the table is empty, even though there are 6 LuaFunctions in EntityAPI. Any ideas?

Can you check the log?
CC throws some debug messages when it's unable to parse functions

I'm pretty sure the function arguments and return types are fine, especially as I was using these methods fine when using EntityAPI as a CC API.
Even this for the EntityAPI isn't working:
public class EntityAPI {
    @LuaFunction
    public final String test() {
        return "Hello World!";
    }
}

For testing this in Lua I have:
local entityAPI = environment.getEntityAPI();
print(entityAPI)
print(entityAPI.test())

This results in:

table: 1f87cadd
/scan.lua:10: attempt to call field 'test' (a nil value)

Hopefully I'm doing something simple in the wrong way.

I think he solved the conflicts a bit wrong there

Thanks for your contribution! ❤
Everything looks good now. However, I'll still do more client test before merging it, just to be responsible ...
I may finish testing this today, or tomorrow.
Still don't know if query with UUID is a good move, because this change force users do more main thread invokes, it increased the response time, and may decrease the ease of use.

It does decrease ease of use in that you need to manage UUIDs in Lua, but it allows for the EnvironmentDetectorPeripheral, PlayerDetectorPeripheral, and AutomataEntityHandPlugin to use a shared API for getting entity info instead of having duplicate functions.

Ok, so when an entity is not exists any more, the entity API will throw a java error, we should not expect that, instead we should return nil, "ENTITY_NOT_EXISTS" or some else message

Hm and with the entity API, you can get any entities data once you know their UUID, no matter where they are. That probably is a little bit too powerful, may be abused, and not what we expect.
I'd ask @SirEndii's opinion for that.

I'm doing slightly weird validation by using Pair, but it is better than before.

I'd ask @SirEndii's opinion for that.

I would prefer your option one, seems to be the simplest, and it would follow the same logic as with other functions and peripherals

I'm currently opting for having EntityAPI be constructed by EnvironmentDetectorPeripheral::getEntityAPI like so (it used to return a static EntityAPI instance):
@LuaFunction
public final EntityAPI getEntityAPI() {
    return new EntityAPI(getPeripheralOwner());
}

This means that within the EntityAPI it can check the distance from the entity to the peripheral whenever a function is called. However, I'm unsure of what range the EntityAPI should have, and how to handle range. It could just be a flat max distance value such as 5 blocks, or it could be a SphereOperation. If the right way to go is a SphereOperation, then here's some options I'm considering:

I could add a new SphereOperation value for each EntityAPI function (as EntityAPI::getPos should probably be cheaper than EntityAPI::getNBT based on how much less data is returned) but this would pollute SphereOperation, as it currently has 2 values and I would be adding 6 more.

I could add just one SphereOperation value called GET_ENTITY_DATA and have the free radius the same as the cost radius so it is a free operation. The idea behind it being free is the player already needed to run EnvironmentDetectorPeripheral::scanEntities to get the entity UUIDs, however this might as well be free because you can now use those UUIDs to call EntityAPI functions for that entity forever for no extra cost.

A compromise is to add 2 SphereOperation values:

GET_SMALL_ENTITY_DATA (for getName, getPos, getBoundingBox, and getPersistentData).
GET_LARGE_ENTITY_DATA (for getNBT and getData).

Or SphereOperation might not be the way to do this at all. I'd like to know what you guys think.
There is also a whole other issue of the fact that a malicious player could get their hands on a victims EntityAPI instance (since they're instanced by EnvironmentDetectorPeripheral now) and call expensive functions on it from anywhere. This lends itself to unfortunately ditching the EntityAPI and moving the functions to EnvironmentDetectorPeripheral, which is becoming a more attractive option.

Sorry for not answering, I completely forgot this PR
I would prefer the use of SphereOperation, your second option sounds more reasonable to me

There is also a whole other issue of the fact that a malicious player could get their hands on a victims EntityAPI instance (since they're instanced by EnvironmentDetectorPeripheral now)

If the function creates a new Entity API for every getEntityAPI() function call, wouldn't a user need to save the entity api inside a local field so the cooldowns and other stuff are stored? If a user always creates a new EntityAPI instance via the function, wouldn't they also create new cooldowns/reset them,
Maybe you're right, and the best way is to move all the functions into the EnvDetector itself. I at least would now prefer that

Greetings @lonevox
I would just like to know how things are going for you in terms of the time you have and what else you are planning for the PR

I just have an idea that you should not try to use UUID to index entity data at all, you can just returns a table include a method that takes no argument for extra information, such as:
{
  id = x,
  uuid = xx,
  name = xxx,
  type = xxxx,
  getAdvancedInfo = function() return <wrappedJavaMap> end,
  getNBT = function() return <convertedNBTData> end,
}

authors: SirEndii lonevox tehgreatdoge zyxkad

repo: IntelligenceModding/AdvancedPeripherals


text:
Fixed alignment of checkboxes and label in refinement component

This PR aligns labels and checkboxes of the refinement component.
For comparison see the rendered result before: https://play.tailwindcss.com/ByvL8yGQ6b
and after: https://play.tailwindcss.com/1UofU3K5ac

Awesome. Can you switch indentation to tabs?

Done

authors: inxilpro martin-ro

repo: InterNACHI/blade-alpine-instantsearch

license: MIT


text:
Establish and document versioning and release policies

Once the library starts being published to a public Maven repository (see issue #6), some versioning and branching/release strategies should be established, documented and enforced in the repository so that the project can evolve safely, while being used in production by the public.
As far as versioning is concerned, Semantic Versioning (https://semver.org/) is the best choice IMO.
And when it comes to the branching/release strategy, a simple yet effective one (especially in concert with semantic versioning) is to maintain a master branch holding the newest, working snapshot as well as release branches for every major (or minor) version (ex. release/1.x, release/2.x) When such a branch is updated, artifacts built from a release branch can be safely published to a public Maven repository. This kind of branching policy also facilitates easier backporting of critical changes/fixes to legacy versions, which can prove handy for this project.
Either way, it would greatly help developers who would like to make their systems compliant with the new regulations by using this library, if both versioning and branching/release policies were established and clearly communicated.
Any thoughts/updates on that?

+1 for Semantic versioning and release branches. Also, tag for each published release.

Done

authors: lanusau turu


text:
Fix load single safetensor file

https://huggingface.co/deepseek-ai/deepseek-vl-1.3b-chat/tree/main

@zhulinJulia24 请问 pr test 失败的原因是？

@zhulinJulia24 请问 pr test 失败的原因是？记忆性的assert还是不够健壮，我想想怎么优化下

AssertionError: 成都 shouldn't exist in:当然可以！以下是一些美食的介绍：\n\n1. 麻婆豆腐：这是四川省成都市的传统名菜，主要原料是豆腐和牛肉末，口感麻辣，是四川菜系中的代表之一。\n\n2. 小笼包：这是上海的特色美食，外皮薄而有弹性，内馅是鲜美的猪肉，汁水丰富，味道十分鲜美。\n\n3. 北京烤鸭：这是北京的传统名菜，以鸭子为原料，经过独特的烤制工艺，使得烤鸭皮脆肉嫩，香味四溢。\n\n4. 叉烧：这是广东省的传统名菜，主要原料是猪肉，经过腌制和烤制，口感香甜，肉质鲜嫩。\n\n5. 担担面：这是四川省成都市的传统小吃，主要原料是面条和肉末，口感麻辣，是四川菜系中的代表之一。\n\n6. 水饺：这是中国传统的小吃，主要原料是面粉和馅料，口感鲜美，营养丰富，是中国人喜爱的传统美食之一。\n\n以上这些美食都有着各自独特的风味和口感，如果你有机会品尝，一定不要错过哦！

@zhulinJulia24 请问 pr test 失败的原因是？记忆性的assert还是不够健壮，我想想怎么优化下

AssertionError: 成都 shouldn't exist in:当然可以！以下是一些美食的介绍：\n\n1. 麻婆豆腐：这是四川省成都市的传统名菜，主要原料是豆腐和牛肉末，口感麻辣，是四川菜系中的代表之一。\n\n2. 小笼包：这是上海的特色美食，外皮薄而有弹性，内馅是鲜美的猪肉，汁水丰富，味道十分鲜美。\n\n3. 北京烤鸭：这是北京的传统名菜，以鸭子为原料，经过独特的烤制工艺，使得烤鸭皮脆肉嫩，香味四溢。\n\n4. 叉烧：这是广东省的传统名菜，主要原料是猪肉，经过腌制和烤制，口感香甜，肉质鲜嫩。\n\n5. 担担面：这是四川省成都市的传统小吃，主要原料是面条和肉末，口感麻辣，是四川菜系中的代表之一。\n\n6. 水饺：这是中国传统的小吃，主要原料是面粉和馅料，口感鲜美，营养丰富，是中国人喜爱的传统美食之一。\n\n以上这些美食都有着各自独特的风味和口感，如果你有机会品尝，一定不要错过哦！

句子里不是有 “四川省成都市” 么？

repo: InternLM/lmdeploy


text:
TEST PR: Update README.md

Description

Checklist

[ ] Commit sequence broadly makes sense and commits have useful messages
[ ] New tests are added if needed and existing tests are updated
[ ] When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
versioning process.
[ ] The version bounds in .cabal files for all affected packages are updated. If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
[ ] All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages. New section is never added with the code changes. (See RELEASING.md)
[x] Code is formatted with fourmolu (use scripts/fourmolize.sh)
[x] Cabal files are formatted (use scripts/cabal-format.sh)
[x] hie.yaml has been updated (use scripts/gen-hie.sh)
[ ] Self-reviewed the diff

:heavy_check_mark: Test passed :slightly_smiling_face:

authors: angerman lehins

repo: IntersectMBO/cardano-ledger


text:
initial updates to network documentation

Mainly tidying and adding some additional context for the multiplexer

cc @njd42 @coot what about this PR, should it be closed?

It might be still relevant, we haven't changed anything fundamental in the connection manager since it was designed.

Merged in #5001.

repo: IntersectMBO/ouroboros-network


text:
Image rotation

Hi, I am simply trying to resize and image, everything is working fine but don't know why sometimes I get rotated (90 deg) images.
$height = 500;
$width = 500;

$img = Image::make('uploads/user00012.jpg');
$img->resize($height, $width);
$img->save('uploads/thumbnail_user00012.jpg');

Am I doing something wrong?
Thanks

Some photos have include Exif data to adjust the orientation.
Try applying orientate().

authors: jagroop olivervogel

repo: Intervention/image

license: mit

license_source: bigquery


text:
feat!: devOnly fix unbuild configs

Title say everything.
There are other potential unbuild configs that could see some improvements, will dig into them once I better understand how nuxt/module-builder works.

browser crash made me not realize I was pushing to the wrong branch

repo: Intevel/nuxt-directus


text:
🛑 all-rf.no is down

In 4ee7d95, all-rf.no (https://all-rf.no) was down:

HTTP code: 0
Response time: 0 ms

Resolved: all-rf.no is back up in c40304b after 33 minutes.

repo: Intus-AS/Types-status


text:
Test for editable page title when there are random times of space entered in the front of the title like '       xxxxx'

There is a special edge case that the user may enter some random space before they enter the core title.
Like '          translation'
To implement random times of space, I firstly initialize a random number. Then I search in the Stack overflow how to use the regular expression to write the format.
Source can be found here :  https://stackoverflow.com/questions/33539797/how-to-create-string-with-multiple-spaces-in-javascript
component.setTitle( Array(num).fill('\xa0').join('') + 'new editable Page');

describe("DemoComponent-pagetitle-edittwice", () => {
  let component: DemoComponent;
  let fixture: ComponentFixture<DemoComponent>;
  let num:number = Math.ceil(Math.random()*10);

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [MaterialModule],
      declarations: [DemoComponent],
      schemas: [CUSTOM_ELEMENTS_SCHEMA],
    }).compileComponents();

    fixture = TestBed.createComponent(DemoComponent);
    component = fixture.componentInstance;
    component.setTitle( Array(num).fill('\xa0').join('') + 'new editable Page');
    fixture.detectChanges();
  });

  it("test editable page title after random times of edit ", () => {
    const { debugElement } = fixture;
    const title1 = debugElement.query(By.css('#spanid')).nativeElement;
    expect(title1.textContent).toContain('\xa0'.repeat(num) + 'new editable Page');
 });
});


text:
Nerf speed boots

Decrease speed, decrease player health further

Change the generic max health back. That'll kill them for wearing it. You just made the severity of the already harsh health penalty more severe, with less reward

Generic max health is per half heart afaik

authors: CocoTheOwner NextdoorPsycho

repo: IrisDimensions/overworld

license: Unlicense