Hi All, Good day! I’ve been doing some PTN3460 programming under Linux using C/C++ and I have some questions regarding on setting the brightness level to my display device. The display device with PTN3460 is connected in DP (display port) to my computer. Only needs a DisplayPort native AUX command to access DPCD address from PTN3460. I’m currently looking into the DRM (Direct Rendering Manager) a subsystem of the Linux kernel. It has a methods drm_dp_dpcd_readb, drm_dp_dpcd_read and drm_dp_dpcd_write.
Do you have any suggestions or advice how to use the kernel driver in DRM in regards to how to implement the method drm_dp_dpcd_readb for example? I couldn't not find any test tool examples that implement it. Biggest concern is I don't have sufficient knowledge where to start what to code using the DRM module.
Namedrm_dp_dpcd_readb — read a single byte from the DPCDSynopsisssize_t drm_dp_dpcd_readb ( struct drm_dp_aux * aux, unsigned int offset, u8 * valuep); Argumentsaux - DisplayPort AUX channeloffset - address of the register to readvaluep - location where the value of the register will be storedDescriptionReturns the number of bytes transferred (1) on success, or a negative error code on failure. Regards,John
On Thu, 17 May 2018, John Sledge john_sledget@yahoo.com wrote:
I’ve been doing some PTN3460 programming under Linux using C/C++ and I have some questions regarding on setting the brightness level to my display device.
The display device with PTN3460 is connected in DP (display port) to my computer. Only needs a DisplayPort native AUX command to access DPCD address from PTN3460. I’m currently looking into the DRM (Direct Rendering Manager) a subsystem of the Linux kernel. It has a methods drm_dp_dpcd_readb, drm_dp_dpcd_read and drm_dp_dpcd_write.
Do you have any suggestions or advice how to use the kernel driver in DRM in regards to how to implement the method drm_dp_dpcd_readb for example? I couldn't not find any test tool examples that implement it. Biggest concern is I don't have sufficient knowledge where to start what to code using the DRM module.
Let me double check, you're talking about doing DPCD access from userspace? The *only* interface that can be recommended for that is the DRM DP AUX interface. If you have kernel config DRM_DP_AUX_CHARDEV=y, you'll get /dev/drm_dp_auxN node(s) that allows you to read and write arbitrary DPCD offsets. It's a chardev; you can use e.g. dd to debug read DPCD.
Of course, it would be better to have a generic backlight interface for DPCD based backlight in kernel. We have the basics for that for Intel GPU in i915/intel_dp_aux_backlight.c. Granted, it should be moved to common DRM code, but it also doesn't work for you if you have the chip connected to regular DP. It expects eDP, and somewhat spec compliant eDP DPCD backlight support.
HTH, Jani.
Hi Jani, Good day! Thank you for taking the time to point out those information. It’s a great help to me. Also apologies for the late reply, your first reply went to my spam inbox, not sure what happen and I was waiting for replies for days. I'm still new to Linux and to DRM. I also need to investigate and learn more about it. Here's what I have done so far. I was able to work on the modeprint test application from the libdrm package found in the website github.com/grate-driver/libdrm. I need to understand how user space and kernel works and modeprint provided me a simple understanding how it works.The modeprint requires a module name to open and I provided the i915 module. It followed opening the device name then calling ioctl commands to get resources, drm mode get connectors, encoders and crtc. From here, i was able to detect the display device's information successfully. So from here I got stuck and got confused. I only notice that in the drm.h it has limited IOCTL commands which it doesn't reach what i needed like to reach scope in drm_dp_helper.c or intel_dp.c where the dp aux read/write functions. Okay, back to your advice. Correct, I'm trying to access DPCD from the userspace. I haven't tried it and I'm not sure how it will goes out. I will try it now and I will give feedback on this.From what I understand, I need to rebuild the entire kernel with modification to Kconfig file (depends on DRM=y) in linux-4.16\drivers\gpu\drm directory. Then expect /dev/drm_dp_auxN node in the system. config DRM_DP_AUX_CHARDEV bool "DRM DP AUX Interface" depends on DRM=y help Choose this option to enable a /dev/drm_dp_auxN node that allows to read and write values to arbitrary DPCD registers on the DP aux channel. The second advice, I guess your correct since the display device i needed to communicate is under Connector: DP-1 and not in Connector: eDP-1. This is based on the application modeprint result. Regards,John
On Friday, May 18, 2018, 5:48:31 PM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote:
On Thu, 17 May 2018, John Sledge john_sledget@yahoo.com wrote:
I’ve been doing some PTN3460 programming under Linux using C/C++ and I have some questions regarding on setting the brightness level to my display device.
The display device with PTN3460 is connected in DP (display port) to my computer. Only needs a DisplayPort native AUX command to access DPCD address from PTN3460. I’m currently looking into the DRM (Direct Rendering Manager) a subsystem of the Linux kernel. It has a methods drm_dp_dpcd_readb, drm_dp_dpcd_read and drm_dp_dpcd_write.
Do you have any suggestions or advice how to use the kernel driver in DRM in regards to how to implement the method drm_dp_dpcd_readb for example? I couldn't not find any test tool examples that implement it. Biggest concern is I don't have sufficient knowledge where to start what to code using the DRM module.
Let me double check, you're talking about doing DPCD access from userspace? The *only* interface that can be recommended for that is the DRM DP AUX interface. If you have kernel config DRM_DP_AUX_CHARDEV=y, you'll get /dev/drm_dp_auxN node(s) that allows you to read and write arbitrary DPCD offsets. It's a chardev; you can use e.g. dd to debug read DPCD.
Of course, it would be better to have a generic backlight interface for DPCD based backlight in kernel. We have the basics for that for Intel GPU in i915/intel_dp_aux_backlight.c. Granted, it should be moved to common DRM code, but it also doesn't work for you if you have the chip connected to regular DP. It expects eDP, and somewhat spec compliant eDP DPCD backlight support.
HTH, Jani.
Hi Jani, I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I could see that the kernel is now 4.6. How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure it correctly? It still unclear to me how to follow what you mean by using DRM DP AUX interface and getting /dev/drm_dp_auxN node(s) that allows me to read and write arbitrary DPCD offsets. Please have comments and advice. Regards,John On Thursday, May 24, 2018, 12:19:55 PM GMT+8, John Sledge john_sledget@yahoo.com wrote:
Hi Jani, Good day! Thank you for taking the time to point out those information. It’s a great help to me. Also apologies for the late reply, your first reply went to my spam inbox, not sure what happen and I was waiting for replies for days. I'm still new to Linux and to DRM. I also need to investigate and learn more about it. Here's what I have done so far. I was able to work on the modeprint test application from the libdrm package found in the website github.com/grate-driver/libdrm. I need to understand how user space and kernel works and modeprint provided me a simple understanding how it works.The modeprint requires a module name to open and I provided the i915 module. It followed opening the device name then calling ioctl commands to get resources, drm mode get connectors, encoders and crtc. From here, i was able to detect the display device's information successfully. So from here I got stuck and got confused. I only notice that in the drm.h it has limited IOCTL commands which it doesn't reach what i needed like to reach scope in drm_dp_helper.c or intel_dp.c where the dp aux read/write functions. Okay, back to your advice. Correct, I'm trying to access DPCD from the userspace. I haven't tried it and I'm not sure how it will goes out. I will try it now and I will give feedback on this.From what I understand, I need to rebuild the entire kernel with modification to Kconfig file (depends on DRM=y) in linux-4.16\drivers\gpu\drm directory. Then expect /dev/drm_dp_auxN node in the system. config DRM_DP_AUX_CHARDEV bool "DRM DP AUX Interface" depends on DRM=y help Choose this option to enable a /dev/drm_dp_auxN node that allows to read and write values to arbitrary DPCD registers on the DP aux channel. The second advice, I guess your correct since the display device i needed to communicate is under Connector: DP-1 and not in Connector: eDP-1. This is based on the application modeprint result. Regards,John
On Friday, May 18, 2018, 5:48:31 PM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote:
On Thu, 17 May 2018, John Sledge john_sledget@yahoo.com wrote:
I’ve been doing some PTN3460 programming under Linux using C/C++ and I have some questions regarding on setting the brightness level to my display device.
The display device with PTN3460 is connected in DP (display port) to my computer. Only needs a DisplayPort native AUX command to access DPCD address from PTN3460. I’m currently looking into the DRM (Direct Rendering Manager) a subsystem of the Linux kernel. It has a methods drm_dp_dpcd_readb, drm_dp_dpcd_read and drm_dp_dpcd_write.
Do you have any suggestions or advice how to use the kernel driver in DRM in regards to how to implement the method drm_dp_dpcd_readb for example? I couldn't not find any test tool examples that implement it. Biggest concern is I don't have sufficient knowledge where to start what to code using the DRM module.
Let me double check, you're talking about doing DPCD access from userspace? The *only* interface that can be recommended for that is the DRM DP AUX interface. If you have kernel config DRM_DP_AUX_CHARDEV=y, you'll get /dev/drm_dp_auxN node(s) that allows you to read and write arbitrary DPCD offsets. It's a chardev; you can use e.g. dd to debug read DPCD.
Of course, it would be better to have a generic backlight interface for DPCD based backlight in kernel. We have the basics for that for Intel GPU in i915/intel_dp_aux_backlight.c. Granted, it should be moved to common DRM code, but it also doesn't work for you if you have the chip connected to regular DP. It expects eDP, and somewhat spec compliant eDP DPCD backlight support.
HTH, Jani.
On Thu, 24 May 2018, John Sledge john_sledget@yahoo.com wrote:
I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I could see that the kernel is now 4.6.
If you're updating kernels, why not update to a recent kernel that's actually supported...?
How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure it correctly?
Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it right.
It still unclear to me how to follow what you mean by using DRM DP AUX interface and getting /dev/drm_dp_auxN node(s) that allows me to read and write arbitrary DPCD offsets.
The device is a char device you can open, seek to an offset (which would be the DPCD offset), and read. For testing, you can achieve the same using dd.
BR, Jani.
Hi Jani, I can now see /dev/drm_dp_aux*. I'm not familiar with dd command.Correct me if I'm wrong. Possible commands i tried and nothing happen:dd if=/dev/drm_dp_aux1 seek=723 ibs=2dd of=/dev/drm_dp_aux1 seek=723 ibs=2 dd if=/dev/drm_dp_aux2 seek=723 ibs=2dd of=/dev/drm_dp_aux2 seek=723 ibs=2 I assumed I could read the brightness msb and lsb using the define in drm_dp_helper.h. #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
From here, I was thinking if I could try to open \dev\drm_dp_aux* then read the brightness offset 0x723, though not sure how to proceed with it.I was able to successfully open \dev\drm_dp_aux1 and \dev\drm_dp_aux2 but I thinking I'm wrong when I proceed to ioctl because they all failed.
#define BRIGHTNESS 0x723 int main(int argc, char ** argv){ int fd; int retcode; char out[128]; if((fd = open("/dev/drm_dp_aux1",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } // trying aux2 if((fd = open("/dev/drm_dp_aux2",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } return 0;} Thanks,John
On Thursday, May 24, 2018, 8:38:02 PM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote:
On Thu, 24 May 2018, John Sledge john_sledget@yahoo.com wrote:
I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I could see that the kernel is now 4.6.
If you're updating kernels, why not update to a recent kernel that's actually supported...?
How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure it correctly?
Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it right.
It still unclear to me how to follow what you mean by using DRM DP AUX interface and getting /dev/drm_dp_auxN node(s) that allows me to read and write arbitrary DPCD offsets.
The device is a char device you can open, seek to an offset (which would be the DPCD offset), and read. For testing, you can achieve the same using dd.
BR, Jani.
On Fri, 25 May 2018, John Sledge john_sledget@yahoo.com wrote:
Hi Jani, I can now see /dev/drm_dp_aux*. I'm not familiar with dd command.Correct me if I'm wrong. Possible commands i tried and nothing happen:dd if=/dev/drm_dp_aux1 seek=723 ibs=2dd of=/dev/drm_dp_aux1 seek=723 ibs=2 dd if=/dev/drm_dp_aux2 seek=723 ibs=2dd of=/dev/drm_dp_aux2 seek=723 ibs=2 I assumed I could read the brightness msb and lsb using the define in drm_dp_helper.h. #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
You're mixing hex and decimal numbers, you should probably use bs=1 count=2, dd outputs binary so you probably need to pipe it to hexdump to see anything, etc. Perhaps start experiments with reading at seek=0.
From here, I was thinking if I could try to open \dev\drm_dp_aux* then read the brightness offset 0x723, though not sure how to proceed with it.I was able to successfully open \dev\drm_dp_aux1 and \dev\drm_dp_aux2 but I thinking I'm wrong when I proceed to ioctl because they all failed.
It's a character device, open, seek, read/write. Don't try any ioctls on it.
Good luck.
BR, Jani.
#define BRIGHTNESS 0x723 int main(int argc, char ** argv){ int fd; int retcode; char out[128]; if((fd = open("/dev/drm_dp_aux1",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } // trying aux2 if((fd = open("/dev/drm_dp_aux2",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } return 0;} Thanks,John
On Thursday, May 24, 2018, 8:38:02 PM GMT+8, Jani Nikula <jani.nikula@linux.intel.com> wrote:
On Thu, 24 May 2018, John Sledge john_sledget@yahoo.com wrote:
I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I could see that the kernel is now 4.6.
If you're updating kernels, why not update to a recent kernel that's actually supported...?
How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure it correctly?
Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it right.
It still unclear to me how to follow what you mean by using DRM DP AUX interface and getting /dev/drm_dp_auxN node(s) that allows me to read and write arbitrary DPCD offsets.
The device is a char device you can open, seek to an offset (which would be the DPCD offset), and read. For testing, you can achieve the same using dd.
BR, Jani.
Hi Jani, I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the brightness value of the display. I also did a test, when I disconnect the DP to the display and execute the dd commands, it would say error reading 'dev/drm_dp_aux1': Connection timed out. So I think my display setup is okay and the 11 0A values are really coming out from the display. Output in hex:11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A ....
int main(int argc, char **argv) { int ret = 0; int offset = 0; char call[100]; for(offset=0;offset<800;offset++) { sprintf(call,"dd if=/dev/drm_dp_aux1 bs=1 count=2 seek=%d >> out.txt",offset); ret = system(call); } return 0;}
Regards,John
On Friday, May 25, 2018, 2:56:04 PM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote:
On Fri, 25 May 2018, John Sledge john_sledget@yahoo.com wrote:
Hi Jani, I can now see /dev/drm_dp_aux*. I'm not familiar with dd command.Correct me if I'm wrong. Possible commands i tried and nothing happen:dd if=/dev/drm_dp_aux1 seek=723 ibs=2dd of=/dev/drm_dp_aux1 seek=723 ibs=2 dd if=/dev/drm_dp_aux2 seek=723 ibs=2dd of=/dev/drm_dp_aux2 seek=723 ibs=2 I assumed I could read the brightness msb and lsb using the define in drm_dp_helper.h. #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
You're mixing hex and decimal numbers, you should probably use bs=1 count=2, dd outputs binary so you probably need to pipe it to hexdump to see anything, etc. Perhaps start experiments with reading at seek=0.
From here, I was thinking if I could try to open \dev\drm_dp_aux* then read the brightness offset 0x723, though not sure how to proceed with it.I was able to successfully open \dev\drm_dp_aux1 and \dev\drm_dp_aux2 but I thinking I'm wrong when I proceed to ioctl because they all failed.
It's a character device, open, seek, read/write. Don't try any ioctls on it.
Good luck.
BR, Jani.
#define BRIGHTNESS 0x723 int main(int argc, char ** argv){ int fd; int retcode; char out[128]; if((fd = open("/dev/drm_dp_aux1",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } // trying aux2 if((fd = open("/dev/drm_dp_aux2",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } return 0;} Thanks,John
On Thursday, May 24, 2018, 8:38:02 PM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote: On Thu, 24 May 2018, John Sledge john_sledget@yahoo.com wrote:
I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I could see that the kernel is now 4.6.
If you're updating kernels, why not update to a recent kernel that's actually supported...?
How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure it correctly?
Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it right.
It still unclear to me how to follow what you mean by using DRM DP AUX interface and getting /dev/drm_dp_auxN node(s) that allows me to read and write arbitrary DPCD offsets.
The device is a char device you can open, seek to an offset (which would be the DPCD offset), and read. For testing, you can achieve the same using dd.
BR, Jani.
On Fri, 25 May 2018, John Sledge john_sledget@yahoo.com wrote:
Hi Jani, I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the brightness value of the display. I also did a test, when I disconnect the DP to the display and execute the dd commands, it would say error reading 'dev/drm_dp_aux1': Connection timed out. So I think my display setup is okay and the 11 0A values are really coming out from the display. Output in hex:11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A ....
int main(int argc, char **argv) { int ret = 0; int offset = 0; char call[100]; for(offset=0;offset<800;offset++) { sprintf(call,"dd if=/dev/drm_dp_aux1 bs=1 count=2 seek=%d >> out.txt",offset); ret = system(call); } return 0;}
Look, in this case dd is for debugging and testing on the command line, to verify your approach before writing C. For your real thing, use the open, read, write, lseek system calls. Don't call dd from C.
I've directed you to the right direction, and this is the right place to ask about drm and kms related stuff. But for the basics, you might be better off asking at stackoverflow or something.
BR, Jani.
Looks like the seek=%d in the sprintf is not working. 0x11 0x0A are being returned by the monitor from DPCD’s 0x0000 and 0x0001 repeatedly. The first is DPCD revision (1.1) and the second is maximum Link Rate (0x0a) which is 2.7 Gbps. You might want to do a printf of call to make sure seek is being set correctly.
Which brings up another issue: eDP Backlight Brightness LSB is at hex 0x723 or 1827 decimal. You might also want to confirm your panel supports DPCD backlight adjustment by reading DPCD 0x701 and confirm bit 0 is set.
Clint
From: Intel-gfx intel-gfx-bounces@lists.freedesktop.org On Behalf Of John Sledge Sent: Friday, May 25, 2018 1:11 AM To: dri-devel@lists.freedesktop.org; Jani Nikula jani.nikula@linux.intel.com Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] DRM Inquiry
Hi Jani,
I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the brightness value of the display. I also did a test, when I disconnect the DP to the display and execute the dd commands, it would say error reading 'dev/drm_dp_aux1': Connection timed out. So I think my display setup is okay and the 11 0A values are really coming out from the display.
Output in hex: 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A ....
int main(int argc, char **argv) { int ret = 0; int offset = 0; char call[100]; for(offset=0;offset<800;offset++) { sprintf(call,"dd if=/dev/drm_dp_aux1 bs=1 count=2 seek=%d >> out.txt",offset); ret = system(call); } return 0; } Regards, John
On Friday, May 25, 2018, 2:56:04 PM GMT+8, Jani Nikula <jani.nikula@linux.intel.commailto:jani.nikula@linux.intel.com> wrote:
On Fri, 25 May 2018, John Sledge <john_sledget@yahoo.commailto:john_sledget@yahoo.com> wrote:
Hi Jani, I can now see /dev/drm_dp_aux*. I'm not familiar with dd command.Correct me if I'm wrong. Possible commands i tried and nothing happen:dd if=/dev/drm_dp_aux1 seek=723 ibs=2dd of=/dev/drm_dp_aux1 seek=723 ibs=2 dd if=/dev/drm_dp_aux2 seek=723 ibs=2dd of=/dev/drm_dp_aux2 seek=723 ibs=2 I assumed I could read the brightness msb and lsb using the define in drm_dp_helper.h. #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
You're mixing hex and decimal numbers, you should probably use bs=1 count=2, dd outputs binary so you probably need to pipe it to hexdump to see anything, etc. Perhaps start experiments with reading at seek=0.
From here, I was thinking if I could try to open \dev\drm_dp_aux* then read the brightness offset 0x723, though not sure how to proceed with it.I was able to successfully open \dev\drm_dp_aux1 and \dev\drm_dp_aux2 but I thinking I'm wrong when I proceed to ioctl because they all failed.
It's a character device, open, seek, read/write. Don't try any ioctls on it.
Good luck.
BR,
Jani.
#define BRIGHTNESS 0x723 int main(int argc, char ** argv){ int fd; int retcode; char out[128]; if((fd = open("/dev/drm_dp_aux1",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } // trying aux2 if((fd = open("/dev/drm_dp_aux2",O_RDWR)) >=0) { printf("open success"); } else { printf("open failed"); } if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed"); } else { printf("ioctl success"); } return 0;} Thanks,John
On Thursday, May 24, 2018, 8:38:02 PM GMT+8, Jani Nikula <jani.nikula@linux.intel.commailto:jani.nikula@linux.intel.com> wrote:
On Thu, 24 May 2018, John Sledge <john_sledget@yahoo.commailto:john_sledget@yahoo.com> wrote:
I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I could see that the kernel is now 4.6.
If you're updating kernels, why not update to a recent kernel that's actually supported...?
How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure it correctly?
Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it right.
It still unclear to me how to follow what you mean by using DRM DP AUX interface and getting /dev/drm_dp_auxN node(s) that allows me to read and write arbitrary DPCD offsets.
The device is a char device you can open, seek to an offset (which would be the DPCD offset), and read. For testing, you can achieve the same using dd.
BR, Jani.
-- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.orgmailto:dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 25 May 2018, "Taylor, Clinton A" clinton.a.taylor@intel.com wrote:
Looks like the seek=%d in the sprintf is not working.
Yeah. Try skip=%d instead.
BR, Jani.
Hi Jani, Thanks for the help. I was able to manage your advice on the drm_dp_aux_chardev. Though I still need to learn more about the DRM vs kernel process flow. Like for example, upon changing/adding DRM_DP_AUX_CHARDEV in kernel .config, How did DRM_DP_AUX_CHARDEV was being invoke here? From the code, I notice character device will be created under drm_dp_aux_register_devnode method. For example I made two kernel 4.6 with DRM_DP_AUX_CHARDEV=y and another kernel 4.6 with DRM_DP_AUX_CHARDEV=n. So the steps was to build and install the kernel with DRM_DP_AUX_CHARDEV=y. Once finish, I tried to reboot and verified the /dev/drm_dp_aux_chardev* and it was there. Now, I will change the .config DRM_DP_AUXCHARDEV=n then follow the steps below to manual build the DRM module. I'm not really sure if I'm correct on this one. 1. rm /dev/drm_dp_aux_chardev* 2. make modules_prepare3. make SUBDIRS=scripts/mod4. make SUBDIRS=drivers/gpu/drm modules5. cp drivers/gpu/drm/i915/i915.ko /lib/modules/4.6.0-94.11-default/kernel/drivers/gpu/drm6. ... I copy all .ko under drm to the lib/modules/4.67. depmod8. modprobe i9159. ... I also modprobe all modules10. reboot The result was /dev/drm_dp_aux_chardev* was still there. My expectation was it would disrepair or remove. Please have comments and advice. Regards,John
On Saturday, May 26, 2018, 1:14:40 AM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote:
On Fri, 25 May 2018, "Taylor, Clinton A" clinton.a.taylor@intel.com wrote:
Looks like the seek=%d in the sprintf is not working.
Yeah. Try skip=%d instead.
BR, Jani.
On Mon, 11 Jun 2018, John Sledge john_sledget@yahoo.com wrote:
Thanks for the help. I was able to manage your advice on the drm_dp_aux_chardev. Though I still need to learn more about the DRM vs kernel process flow. Like for example, upon changing/adding DRM_DP_AUX_CHARDEV in kernel .config, How did DRM_DP_AUX_CHARDEV was being invoke here? From the code, I notice character device will be created under drm_dp_aux_register_devnode method. For example I made two kernel 4.6 with DRM_DP_AUX_CHARDEV=y and another kernel 4.6 with DRM_DP_AUX_CHARDEV=n. So the steps was to build and install the kernel with DRM_DP_AUX_CHARDEV=y. Once finish, I tried to reboot and verified the /dev/drm_dp_aux_chardev* and it was there. Now, I will change the .config DRM_DP_AUXCHARDEV=n then follow the steps below to manual build the DRM module. I'm not really sure if I'm correct on this one.
Why are you disabling it again? Just enable the config, use the resulting kernel, and do the rest in userspace.
- rm /dev/drm_dp_aux_chardev* 2. make modules_prepare3. make
SUBDIRS=scripts/mod4. make SUBDIRS=drivers/gpu/drm modules5. cp drivers/gpu/drm/i915/i915.ko /lib/modules/4.6.0-94.11-default/kernel/drivers/gpu/drm6. ... I copy all .ko under drm to the lib/modules/4.67. depmod8. modprobe i9159. ... I also modprobe all modules10. reboot The result was /dev/drm_dp_aux_chardev* was still there. My expectation was it would disrepair or remove.
Don't do this. I don't understand what you're trying to do.
Please have comments and advice.
Please explain what you're trying to do to begin with. What's your end goal?
BR, Jani.
PS. Please prefer plain text instead of html on the list.
Hi Jani, I like to understand how the DRM_DP_AUX_CHARDEV=y kick off. Regards,John
On Monday, June 11, 2018, 7:36:51 PM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote:
On Mon, 11 Jun 2018, John Sledge john_sledget@yahoo.com wrote:
Thanks for the help. I was able to manage your advice on the drm_dp_aux_chardev. Though I still need to learn more about the DRM vs kernel process flow. Like for example, upon changing/adding DRM_DP_AUX_CHARDEV in kernel .config, How did DRM_DP_AUX_CHARDEV was being invoke here? From the code, I notice character device will be created under drm_dp_aux_register_devnode method. For example I made two kernel 4.6 with DRM_DP_AUX_CHARDEV=y and another kernel 4.6 with DRM_DP_AUX_CHARDEV=n. So the steps was to build and install the kernel with DRM_DP_AUX_CHARDEV=y. Once finish, I tried to reboot and verified the /dev/drm_dp_aux_chardev* and it was there. Now, I will change the .config DRM_DP_AUXCHARDEV=n then follow the steps below to manual build the DRM module. I'm not really sure if I'm correct on this one.
Why are you disabling it again? Just enable the config, use the resulting kernel, and do the rest in userspace.
- rm /dev/drm_dp_aux_chardev* 2. make modules_prepare3. make
SUBDIRS=scripts/mod4. make SUBDIRS=drivers/gpu/drm modules5. cp drivers/gpu/drm/i915/i915.ko /lib/modules/4.6.0-94.11-default/kernel/drivers/gpu/drm6. ... I copy all .ko under drm to the lib/modules/4.67. depmod8. modprobe i9159. ... I also modprobe all modules10. reboot The result was /dev/drm_dp_aux_chardev* was still there. My expectation was it would disrepair or remove.
Don't do this. I don't understand what you're trying to do.
Please have comments and advice.
Please explain what you're trying to do to begin with. What's your end goal?
BR, Jani.
PS. Please prefer plain text instead of html on the list.
On Wed, 13 Jun 2018, John Sledge john_sledget@yahoo.com wrote:
I like to understand how the DRM_DP_AUX_CHARDEV=y kick off.
Try 'git grep DRM_DP_AUX_CHARDEV' in your kernel git repo, and see how it affects conditional compilation.
This list isn't kernel development 101.
You still didn't say what your end goal is. Forget everything about DP AUX and the chardev and so on, just tell us what you're trying to achieve. Maybe you're asking about X, but you really want to know about Y.
BR, Jani.
Hi Jani, The end goal was already achieve by the advice you gave the DRM_DP_AUX_CHARDEV.I just like to extend my knowledge into DRM such as a scenario having a kernel version that doesn't have the DRM_DP_AUX_CHARDEV yet. Would it possible to implement specific DRM_DP_AUX_CHARDEV to it. Thanks,John On Wednesday, June 13, 2018, 3:07:14 PM GMT+8, Jani Nikula jani.nikula@linux.intel.com wrote:
On Wed, 13 Jun 2018, John Sledge john_sledget@yahoo.com wrote:
I like to understand how the DRM_DP_AUX_CHARDEV=y kick off.
Try 'git grep DRM_DP_AUX_CHARDEV' in your kernel git repo, and see how it affects conditional compilation.
This list isn't kernel development 101.
You still didn't say what your end goal is. Forget everything about DP AUX and the chardev and so on, just tell us what you're trying to achieve. Maybe you're asking about X, but you really want to know about Y.
BR, Jani.
dri-devel@lists.freedesktop.org