Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
> > > > > > Hi Thomas, > > > > > > I am working on adding gen2 VM support and cursor support. Also > > > for my > > > next interation moving the driver out of tiny. Progress is slow > > > lately > > > as busy with other stuff at work. Hopefully I will be able to > > > finish > > > during coming holidays. > > > > I see. Thanks for the update. I'd suggest to clean up what you have > > and > > send it for review. Having even a simple driver in upstream makes > > it so > > much easier for others to contribute and you'll get many of the > > upstream > > improvements automatically. > > Seconded, once we have some basics (like gen1 only, no cursor > support) > landing incremental changes tends to be much easier than the initial > driver. > > So adding more features and trying to make it as complete as possible > before you want to land it might just be detriminal to overall > upstreaming > speed. Usually at least. > Thanks Thomas and Daniel, I will quickly submit a patches with gen1/2 without cursor support later next week. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Sun, Nov 15, 2020 at 07:58:00PM +0100, Thomas Zimmermann wrote: > Hi > > Am 15.11.20 um 18:55 schrieb Deepak Rawat: > > On Sun, 2020-11-15 at 10:14 +0100, Thomas Zimmermann wrote: > >> Hi Deepak > >> > >> Am 11.09.20 um 02:38 schrieb Deepak Rawat: > >>> On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: > Hi Deepak, > > Do you have a new version of this patch now? > I take a try with it. and meet some typo and “incompatible > pointer” > error. > If you have a new version, could you share it with us? > > >>> > >>> Hi Shaofeng, > >>> > >>> It seems you are running this with gen 2 VM, I have a patch to > >>> support > >>> gen 2 VM's at https://github.com/deepak-rawat/linux.git branch > >>> hyperv_t > >>> iny. > >> > >> I'm interested in merging this driver into the DRM upstream. What's > >> the > >> status? Are you still working on it? > > > > Hi Thomas, > > > > I am working on adding gen2 VM support and cursor support. Also for my > > next interation moving the driver out of tiny. Progress is slow lately > > as busy with other stuff at work. Hopefully I will be able to finish > > during coming holidays. > > I see. Thanks for the update. I'd suggest to clean up what you have and > send it for review. Having even a simple driver in upstream makes it so > much easier for others to contribute and you'll get many of the upstream > improvements automatically. Seconded, once we have some basics (like gen1 only, no cursor support) landing incremental changes tends to be much easier than the initial driver. So adding more features and trying to make it as complete as possible before you want to land it might just be detriminal to overall upstreaming speed. Usually at least. Cheers, Daniel > > Best regards > Thomas > > > > > Deepak > > > >> > >> Best regards > >> Thomas > >> > >>> > >>> If you still run into error after applying gen2 patch, feel free to > >>> reach out with details. > >>> > >>> Deepak > >>> > > BR, Shaofeng > >>> > >>> ___ > >>> dri-devel mailing list > >>> dri-devel@lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >>> > >> > > > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Am 15.11.20 um 18:55 schrieb Deepak Rawat: > On Sun, 2020-11-15 at 10:14 +0100, Thomas Zimmermann wrote: >> Hi Deepak >> >> Am 11.09.20 um 02:38 schrieb Deepak Rawat: >>> On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: Hi Deepak, Do you have a new version of this patch now? I take a try with it. and meet some typo and “incompatible pointer” error. If you have a new version, could you share it with us? >>> >>> Hi Shaofeng, >>> >>> It seems you are running this with gen 2 VM, I have a patch to >>> support >>> gen 2 VM's at https://github.com/deepak-rawat/linux.git branch >>> hyperv_t >>> iny. >> >> I'm interested in merging this driver into the DRM upstream. What's >> the >> status? Are you still working on it? > > Hi Thomas, > > I am working on adding gen2 VM support and cursor support. Also for my > next interation moving the driver out of tiny. Progress is slow lately > as busy with other stuff at work. Hopefully I will be able to finish > during coming holidays. I see. Thanks for the update. I'd suggest to clean up what you have and send it for review. Having even a simple driver in upstream makes it so much easier for others to contribute and you'll get many of the upstream improvements automatically. Best regards Thomas > > Deepak > >> >> Best regards >> Thomas >> >>> >>> If you still run into error after applying gen2 patch, feel free to >>> reach out with details. >>> >>> Deepak >>> BR, Shaofeng >>> >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >> > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Sun, 2020-11-15 at 10:14 +0100, Thomas Zimmermann wrote: > Hi Deepak > > Am 11.09.20 um 02:38 schrieb Deepak Rawat: > > On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: > > > Hi Deepak, > > > > > > Do you have a new version of this patch now? > > > I take a try with it. and meet some typo and “incompatible > > > pointer” > > > error. > > > If you have a new version, could you share it with us? > > > > > > > Hi Shaofeng, > > > > It seems you are running this with gen 2 VM, I have a patch to > > support > > gen 2 VM's at https://github.com/deepak-rawat/linux.git branch > > hyperv_t > > iny. > > I'm interested in merging this driver into the DRM upstream. What's > the > status? Are you still working on it? Hi Thomas, I am working on adding gen2 VM support and cursor support. Also for my next interation moving the driver out of tiny. Progress is slow lately as busy with other stuff at work. Hopefully I will be able to finish during coming holidays. Deepak > > Best regards > Thomas > > > > > If you still run into error after applying gen2 patch, feel free to > > reach out with details. > > > > Deepak > > > > > > > > BR, Shaofeng > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Deepak Am 11.09.20 um 02:38 schrieb Deepak Rawat: > On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: >> Hi Deepak, >> >> Do you have a new version of this patch now? >> I take a try with it. and meet some typo and “incompatible pointer” >> error. >> If you have a new version, could you share it with us? >> > > Hi Shaofeng, > > It seems you are running this with gen 2 VM, I have a patch to support > gen 2 VM's at https://github.com/deepak-rawat/linux.git branch hyperv_t > iny. I'm interested in merging this driver into the DRM upstream. What's the status? Are you still working on it? Best regards Thomas > > If you still run into error after applying gen2 patch, feel free to > reach out with details. > > Deepak > >> >> BR, Shaofeng > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Deepak, I have tested your patch using Fedora 32 as a guest and Windows 10 Pro 1809 as host (Gen 2 VM). No issues with building or loading the kernel module and I have successfully run SwayWM inside VM using hyperv_drm. Unfortunately, I'm unable to change the resolution beyond FHD. I have a WQHD monitor and I would like to utilize it fully with VM running in full-screen mode but SwayWM detects only FHD as a max available resolution. Also, performance is less than desirable, even mouse pointer rendering is sluggish. I'm a poor C programmer so I won't be very helpful with development but let me know if there is anything I can do to help with testing future versions of this patch. This is something that I really would like to see in future kernel releases. -- Regards Marcin Skarbek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Thu, 2020-09-10 at 08:19 +, Tang, Shaofeng wrote: > Hi Deepak, > > Do you have a new version of this patch now? > I take a try with it. and meet some typo and “incompatible pointer” > error. > If you have a new version, could you share it with us? > Hi Shaofeng, It seems you are running this with gen 2 VM, I have a patch to support gen 2 VM's at https://github.com/deepak-rawat/linux.git branch hyperv_t iny. If you still run into error after applying gen2 patch, feel free to reach out with details. Deepak > > BR, Shaofeng ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Deepak, Do you have a new version of this patch now? I take a try with it. and meet some typo and "incompatible pointer" error. If you have a new version, could you share it with us? BR, Shaofeng ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
> > > Thanks for the review. Unfortunately only the first vmbus message > > > take > > > effect and subsequent calls are ignored. I originally implemented > > > using > > > vram helpers but I figured out calling this vmbus message again > > > won't > > > change the vram location. > > /me notices there also is user_ctx. What is this? Not sure, I will try to get in touch with hyper-v folks internally to see if page-flip can be used. > > > I think that needs a very big comment. Maybe even enforce that with > > a > > "vram_gpa_set" boolean in the device structure, and complain if we > > try to > > do that twice. > > > > Also I guess congrats to microsoft for defining things like that :- > > / > > I would be kind of surprised if the virtual device doesn't support > pageflips. Maybe setting vram_gpa just isn't the correct way to do > it. Is there a specification available? > > There are a number of microsoft folks in Cc: Anyone willing to > comment? > > thanks, > Gerd > > PS: And, yes, in case pageflips really don't work going with shmem > helpers + blits is reasonable. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Deepak Rawat
> Sent: Monday, June 22, 2020 11:49 PM
> > [...]
> > Some quick comments:
> > 1. hyperv_vmbus_probe() assumes the existence of the PCI device,
> > which
> > is not true in a Hyper-V Generation-2 VM.
>
> I guess that mean for Gen-2 VM need to rely on vmbus_allocate_mmio to
> get the VRAM memory? From what I understand the pci interface anyway
> maps to vmbus.
In a Hyper-V Generaton-2 VM, there is not the legacy Hyper-V PCI framebuffer
device, so we have to call vmbus_allocate_mmio() to get a proper MMIO
range and use that as the VRAM memory.
BTW, what's the equivlent of FB_DEFERRED_IO in DRM? Have the patch
implemented the similar thing for DRM like this for FB in this patch:
d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame
buffer driver")
There is also another important performance improvement patch:
3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV
Gen 1 VMs.")
Is the same idea applicable to this DRM patch?
The pci-hyperv FB driver and this DRM driver should not try to load at
the same time. Not sure what should be done to make sure that won't happen.
> > 2. It looks some other functionality in the hyperv_fb driver has not
> > been
> > implemented in this new driver either, e.g. the handling of the
> > SYNTHVID_FEATURE_CHANGE msg.
>
> I deliberately left this and things seems to work without this, maybe I
> need to do more testing. I don't really understand the use-case
> of SYNTHVID_FEATURE_CHANGE. I observed this message was received just
> after vmbus connect and DRM is not yet initialized so no point updating
> the situation. Even otherwise situation (mode, damage, etc.) is
> triggered from user-space, not sure what to update. But will definitely
> clarify on this.
When Linux VM updates the VRAM, Linux should notify the host of the
dirty rectangle, and then the host refreshes the rectangle in the VM
Connectin window so the user sees the updated part of the screen.
I remember when the user closes the VM Connection window, the host
sends the VM a msg with msg->feature_chg.is_dirt_needed=0, so the VM
doesn't have to notify the host of the dirty rectangle; when the VM
Connection program runs again, the VM will receive a msg with
msg->feature_chg.is_dirt_needed=1.
Thanks,
-- Dexuan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi, > > > > + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp; > > > > + msg->vram.is_vram_gpa_specified = 1; > > > > + synthvid_send(hdev, msg); > > > > > > That suggests it is possible to define multiple framebuffers in vram, > > > then pageflip by setting vram.vram_gpa. If that is the case I'm > > > wondering whenever vram helpers are a better fit maybe? You don't > > > have > > > to blit each and every display update then. > > > > Thanks for the review. Unfortunately only the first vmbus message take > > effect and subsequent calls are ignored. I originally implemented using > > vram helpers but I figured out calling this vmbus message again won't > > change the vram location. /me notices there also is user_ctx. What is this? > I think that needs a very big comment. Maybe even enforce that with a > "vram_gpa_set" boolean in the device structure, and complain if we try to > do that twice. > > Also I guess congrats to microsoft for defining things like that :-/ I would be kind of surprised if the virtual device doesn't support pageflips. Maybe setting vram_gpa just isn't the correct way to do it. Is there a specification available? There are a number of microsoft folks in Cc: Anyone willing to comment? thanks, Gerd PS: And, yes, in case pageflips really don't work going with shmem helpers + blits is reasonable. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Deepak Rawat > Sent: Monday, June 22, 2020 4:06 AM > > DRM driver for hyperv synthetic video device, based on hyperv_fb > framebuffer driver. Also added config option "DRM_HYPERV" to enabled > this driver. Hi Deepak, I had a quick look and overall the patch as v1 looks good to me. Some quick comments: 1. hyperv_vmbus_probe() assumes the existence of the PCI device, which is not true in a Hyper-V Generation-2 VM. 2. It looks some other functionality in the hyperv_fb driver has not been implemented in this new driver either, e.g. the handling of the SYNTHVID_FEATURE_CHANGE msg. Thanks, -- Dexuan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Mon, Jun 22, 2020 at 03:20:34PM -0700, Deepak Rawat wrote:
> On Mon, 2020-06-22 at 14:46 +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > +/* Should be done only once during init and resume */
> > > +static int synthvid_update_vram_location(struct hv_device *hdev,
> > > + phys_addr_t vram_pp)
> > > +{
> > > + struct hyperv_device *hv = hv_get_drvdata(hdev);
> > > + struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> > > + unsigned long t;
> > > + int ret = 0;
> > > +
> > > + memset(msg, 0, sizeof(struct synthvid_msg));
> > > + msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> > > + msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> > > + sizeof(struct synthvid_vram_location);
> > > + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> > > + msg->vram.is_vram_gpa_specified = 1;
> > > + synthvid_send(hdev, msg);
> >
> > That suggests it is possible to define multiple framebuffers in vram,
> > then pageflip by setting vram.vram_gpa. If that is the case I'm
> > wondering whenever vram helpers are a better fit maybe? You don't
> > have
> > to blit each and every display update then.
>
> Thanks for the review. Unfortunately only the first vmbus message take
> effect and subsequent calls are ignored. I originally implemented using
> vram helpers but I figured out calling this vmbus message again won't
> change the vram location.
I think that needs a very big comment. Maybe even enforce that with a
"vram_gpa_set" boolean in the device structure, and complain if we try to
do that twice.
Also I guess congrats to microsoft for defining things like that :-/
-Daniel
>
> >
> > FYI: cirrus goes the blit route because (a) the amount of vram is
> > very
> > small so trying to store multiple framebuffers there is out of
> > question,
> > and (b) cirrus converts formats on the fly to hide some hardware
> > oddities.
> >
> > take care,
> > Gerd
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Am 23.06.20 um 11:12 schrieb Deepak Rawat: > On Tue, 2020-06-23 at 09:59 +0200, Thomas Zimmermann wrote: >> Hi Deepak >> >> I did not receive you pat series, so I can only comment on Sam's >> reply. >> See below for some points. > > Hi Thomas, Thanks for the review. I wanted to add you in cc list but > messed it up with final git send-email. Sorry about that. I am not sure > why you didn't received it via dri-devel. The patch series do show up > in dri-devel archive. I wonder if other people also have similar > issues. I think it's related to a problem on my side. Some of my email infrastructure was not available over the weekend. Best regards Thomas > > + struct hv_device *hdev; +}; + +#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev) >> >> Could this be a function? > > Is there a reason to use a function here? > >> + +/* --- --- */ +/* Hyper-V Synthetic Video Protocol */ >> >> The comments look awkward. Unless this style has been used within >> DRM, >> maybe just use >> >> /* >> * ... >> */ >> > > This style is copy-paste from cirrus, and bochs also have same style. > Perhaps historical. Anyway I agree to I should get rid of this. > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Tue, 2020-06-23 at 09:59 +0200, Thomas Zimmermann wrote: > Hi Deepak > > I did not receive you pat series, so I can only comment on Sam's > reply. > See below for some points. Hi Thomas, Thanks for the review. I wanted to add you in cc list but messed it up with final git send-email. Sorry about that. I am not sure why you didn't received it via dri-devel. The patch series do show up in dri-devel archive. I wonder if other people also have similar issues. > > > > > > + struct hv_device *hdev; > > > +}; > > > + > > > +#define to_hv(_dev) container_of(_dev, struct hyperv_device, > > > dev) > > Could this be a function? Is there a reason to use a function here? > > > > + > > > +/* --- > > > --- */ > > > +/* Hyper-V Synthetic Video > > > Protocol */ > > The comments look awkward. Unless this style has been used within > DRM, > maybe just use > > /* > * ... > */ > This style is copy-paste from cirrus, and bochs also have same style. Perhaps historical. Anyway I agree to I should get rid of this. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Deepak
I did not receive you pat series, so I can only comment on Sam's reply.
See below for some points.
Am 22.06.20 um 17:19 schrieb Sam Ravnborg:
> Hi Deepak
>
> On Mon, Jun 22, 2020 at 04:06:22AM -0700, Deepak Rawat wrote:
>> DRM driver for hyperv synthetic video device, based on hyperv_fb
>> framebuffer driver. Also added config option "DRM_HYPERV" to enabled
>> this driver.
>
> Just a buch of drive-by comments while browsing the code.
> In general code looks good, especialyl for a v1.
>
> There is a few places that triggers warnings with checkpatch --strict
> Most looks like things that should be fixed.
>
>
> Sam
>
>>
>> Signed-off-by: Deepak Rawat
>> ---
>> drivers/gpu/drm/tiny/Kconfig |9 +
>> drivers/gpu/drm/tiny/Makefile |1 +
>> drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
>> 3 files changed, 1017 insertions(+)
>> create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c
>>
>> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
>> index 2b6414f0fa75..e6d53e60a9c2 100644
>> --- a/drivers/gpu/drm/tiny/Kconfig
>> +++ b/drivers/gpu/drm/tiny/Kconfig
>> @@ -28,6 +28,15 @@ config DRM_GM12U320
>> This is a KMS driver for projectors which use the GM12U320 chipset
>> for video transfer over USB2/3, such as the Acer C120 mini projector.
>>
>> +config DRM_HYPERV
>> +tristate "DRM Support for hyperv synthetic video device"
>> +depends on DRM && PCI && MMU && HYPERV
>> +select DRM_KMS_HELPER
>> +select DRM_GEM_SHMEM_HELPER
>> +help
>> + This is a KMS driver for for hyperv synthetic video device.
>> + If M is selected the module will be called hyperv_drm.
>> +
>> config TINYDRM_HX8357D
>> tristate "DRM support for HX8357D display panels"
>> depends on DRM && SPI
>> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
>> index 6ae4e9e5a35f..837cb2c2637e 100644
>> --- a/drivers/gpu/drm/tiny/Makefile
>> +++ b/drivers/gpu/drm/tiny/Makefile
>> @@ -2,6 +2,7 @@
>>
>> obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
>> obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
>> +obj-$(CONFIG_DRM_HYPERV)+= hyperv_drm.o
>> obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
>> obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
>> obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
>> diff --git a/drivers/gpu/drm/tiny/hyperv_drm.c
>> b/drivers/gpu/drm/tiny/hyperv_drm.c
>> new file mode 100644
>> index ..3d020586056e
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tiny/hyperv_drm.c
>> @@ -0,0 +1,1007 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright 2012-2020 Microsoft
>> + *
>> + * Authors:
>> + * Deepak Rawat
>> + *
>> + * Portions of this code is derived from hyperv_fb.c
>> + * drivers/video/fbdev/hyperv_fb.c - framebuffer driver for hyperv synthetic
>> + * video device.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
> Alphabetic order.
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
> Needed?
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
>> +
>> +#define DRIVER_NAME "hyperv_drm"
>> +#define DRIVER_DESC "DRM driver for hyperv synthetic video device"
>> +#define DRIVER_DATE "2020"
>> +#define DRIVER_MAJOR 1
>> +#define DRIVER_MINOR 0
>> +
>> +#define VMBUS_MAX_PACKET_SIZE 0x4000
>> +#define VMBUS_RING_BUFSIZE (256 * 1024)
>> +#define VMBUS_VSP_TIMEOUT (10 * HZ)
>> +
>> +#define PCI_VENDOR_ID_MICROSOFT 0x1414
>> +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
>> +
>> +struct hyperv_device {
>
> This is much more than a device - maybe just name it "struct hv"?
I think hyperv_device is good. And it's much more than just 'hv'.
>
>> +/* drm */
>> +struct drm_device dev;
>> +struct drm_simple_display_pipe pipe;
>> +struct drm_connector connector;
>> +
>> +/* mode */
>> +u32 screen_width_max;
>> +u32 screen_height_max;
>> +u32 preferred_width;
>> +u32 preferred_height;
>> +u32 screen_depth;
>> +
>> +/* hw */
>> +void __iomem *vram;
>> +unsigned long fb_base;
>> +unsigned long fb_size;
>> +struct completion wait;
>> +u32 synthvid_version;
>> +u32 mmio_megabytes;
>> +bool init_done;
This field is unused. Please remove.
>> +
>> +u8 init_buf[VMBUS_MAX_PACKET_SIZE];
>> +u8 recv_buf[VMBUS_MAX_PACKET_SIZE];
>> +
>> +struct hv_device *hdev;
>> +};
>> +
>> +#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev)
Could this be a function?
>> +
>> +/* -- */
>> +/* Hyper-V Synthetic Video Protocol */
The comments look awkward. Unless this style has been used within DRM,
maybe just use
/*
* ...
*/
>> +
>> +#define SYNTHVID_VERSION(major, minor) ((minor) <
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Tue, 2020-06-23 at 02:31 +, Dexuan Cui wrote: > > From: linux-hyperv-ow...@vger.kernel.org > > On Behalf Of Deepak Rawat > > Sent: Monday, June 22, 2020 4:06 AM > > > > DRM driver for hyperv synthetic video device, based on hyperv_fb > > framebuffer driver. Also added config option "DRM_HYPERV" to > > enabled > > this driver. > > Hi Deepak, > I had a quick look and overall the patch as v1 looks good to me. Thanks Dexuan for the review. > > Some quick comments: > 1. hyperv_vmbus_probe() assumes the existence of the PCI device, > which > is not true in a Hyper-V Generation-2 VM. I guess that mean for Gen-2 VM need to rely on vmbus_allocate_mmio to get the VRAM memory? From what I understand the pci interface anyway maps to vmbus. > > 2. It looks some other functionality in the hyperv_fb driver has not > been > implemented in this new driver either, e.g. the handling of the > SYNTHVID_FEATURE_CHANGE msg. I deliberately left this and things seems to work without this, maybe I need to do more testing. I don't really understand the use-case of SYNTHVID_FEATURE_CHANGE. I observed this message was received just after vmbus connect and DRM is not yet initialized so no point updating the situation. Even otherwise situation (mode, damage, etc.) is triggered from user-space, not sure what to update. But will definitely clarify on this. > > Thanks, > -- Dexuan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
>
> Just a buch of drive-by comments while browsing the code.
> In general code looks good, especialyl for a v1.
>
> There is a few places that triggers warnings with checkpatch --strict
> Most looks like things that should be fixed.
>
>
Thanks Sam for the review. Will take care of the suggestions in next
iteration.
Response inlined below:
> > +struct pipe_msg_hdr {
> > + u32 type;
> > + u32 size; /* size of message after this field */
> > +} __packed;
> > +
> > +struct hvd_screen_info {
> > + u16 width;
> > + u16 height;
> > +} __packed;
> > +
> > +struct synthvid_msg_hdr {
> > + u32 type;
> > + u32 size; /* size of this header + payload after this field*/
> Add space before closing "*/"
>
> I wonder what is the difference between what is considered a message
> and
> what is considered payload in the above comments.
> Maybe that just because I do not know this stuff at all and the
> comment
> can be ignored.
message = struct pipe_msg_hdr + struct synthvid_msg_hdr + payload
Will try to make it more clear.
>
> > +} __packed;
> > +
> > +struct synthvid_version_req {
> > + u32 version;
> > +} __packed;
> > +
> > +struct synthvid_version_resp {
> > + u32 version;
> > + u8 is_accepted;
> > + u8 max_video_outputs;
> > +} __packed;
> > +
> > +struct synthvid_vram_location {
> > + u64 user_ctx;
> > + u8 is_vram_gpa_specified;
> > + u64 vram_gpa;
> > +} __packed;
> Not an alignmnet friendly layout - but I guess the layout is fixed.
> Same goes in otther places.
Yes nothing can be done for this.
>
> > +static int synthvid_update_situation(struct hv_device *hdev, u8
> > active, u32 bpp,
> > +u32 w, u32 h, u32 pitch)
> > +{
> > + struct synthvid_msg msg;
>
> Sometimes synthvid_msg is hv->init_buf.
> Sometimes a local variable.
> I wonder why there is a difference.
When a reply is expected, hv->init_buf should be used, though I haven't
verified this. Just kept the same logic as in framebuffer driver.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Mon, 2020-06-22 at 14:46 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > +/* Should be done only once during init and resume */
> > +static int synthvid_update_vram_location(struct hv_device *hdev,
> > + phys_addr_t vram_pp)
> > +{
> > + struct hyperv_device *hv = hv_get_drvdata(hdev);
> > + struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> > + unsigned long t;
> > + int ret = 0;
> > +
> > + memset(msg, 0, sizeof(struct synthvid_msg));
> > + msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> > + msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> > + sizeof(struct synthvid_vram_location);
> > + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> > + msg->vram.is_vram_gpa_specified = 1;
> > + synthvid_send(hdev, msg);
>
> That suggests it is possible to define multiple framebuffers in vram,
> then pageflip by setting vram.vram_gpa. If that is the case I'm
> wondering whenever vram helpers are a better fit maybe? You don't
> have
> to blit each and every display update then.
Thanks for the review. Unfortunately only the first vmbus message take
effect and subsequent calls are ignored. I originally implemented using
vram helpers but I figured out calling this vmbus message again won't
change the vram location.
>
> FYI: cirrus goes the blit route because (a) the amount of vram is
> very
> small so trying to store multiple framebuffers there is out of
> question,
> and (b) cirrus converts formats on the fly to hide some hardware
> oddities.
>
> take care,
> Gerd
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Deepak
On Mon, Jun 22, 2020 at 04:06:22AM -0700, Deepak Rawat wrote:
> DRM driver for hyperv synthetic video device, based on hyperv_fb
> framebuffer driver. Also added config option "DRM_HYPERV" to enabled
> this driver.
Just a buch of drive-by comments while browsing the code.
In general code looks good, especialyl for a v1.
There is a few places that triggers warnings with checkpatch --strict
Most looks like things that should be fixed.
Sam
>
> Signed-off-by: Deepak Rawat
> ---
> drivers/gpu/drm/tiny/Kconfig |9 +
> drivers/gpu/drm/tiny/Makefile |1 +
> drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
> 3 files changed, 1017 insertions(+)
> create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c
>
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index 2b6414f0fa75..e6d53e60a9c2 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -28,6 +28,15 @@ config DRM_GM12U320
>This is a KMS driver for projectors which use the GM12U320 chipset
>for video transfer over USB2/3, such as the Acer C120 mini projector.
>
> +config DRM_HYPERV
> + tristate "DRM Support for hyperv synthetic video device"
> + depends on DRM && PCI && MMU && HYPERV
> + select DRM_KMS_HELPER
> + select DRM_GEM_SHMEM_HELPER
> + help
> + This is a KMS driver for for hyperv synthetic video device.
> + If M is selected the module will be called hyperv_drm.
> +
> config TINYDRM_HX8357D
> tristate "DRM support for HX8357D display panels"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
> index 6ae4e9e5a35f..837cb2c2637e 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -2,6 +2,7 @@
>
> obj-$(CONFIG_DRM_CIRRUS_QEMU)+= cirrus.o
> obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
> +obj-$(CONFIG_DRM_HYPERV) += hyperv_drm.o
> obj-$(CONFIG_TINYDRM_HX8357D)+= hx8357d.o
> obj-$(CONFIG_TINYDRM_ILI9225)+= ili9225.o
> obj-$(CONFIG_TINYDRM_ILI9341)+= ili9341.o
> diff --git a/drivers/gpu/drm/tiny/hyperv_drm.c
> b/drivers/gpu/drm/tiny/hyperv_drm.c
> new file mode 100644
> index ..3d020586056e
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/hyperv_drm.c
> @@ -0,0 +1,1007 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2012-2020 Microsoft
> + *
> + * Authors:
> + * Deepak Rawat
> + *
> + * Portions of this code is derived from hyperv_fb.c
> + * drivers/video/fbdev/hyperv_fb.c - framebuffer driver for hyperv synthetic
> + * video device.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
Alphabetic order.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Needed?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "hyperv_drm"
> +#define DRIVER_DESC "DRM driver for hyperv synthetic video device"
> +#define DRIVER_DATE "2020"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +#define VMBUS_MAX_PACKET_SIZE 0x4000
> +#define VMBUS_RING_BUFSIZE (256 * 1024)
> +#define VMBUS_VSP_TIMEOUT (10 * HZ)
> +
> +#define PCI_VENDOR_ID_MICROSOFT 0x1414
> +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> +
> +struct hyperv_device {
This is much more than a device - maybe just name it "struct hv"?
> + /* drm */
> + struct drm_device dev;
> + struct drm_simple_display_pipe pipe;
> + struct drm_connector connector;
> +
> + /* mode */
> + u32 screen_width_max;
> + u32 screen_height_max;
> + u32 preferred_width;
> + u32 preferred_height;
> + u32 screen_depth;
> +
> + /* hw */
> + void __iomem *vram;
> + unsigned long fb_base;
> + unsigned long fb_size;
> + struct completion wait;
> + u32 synthvid_version;
> + u32 mmio_megabytes;
> + bool init_done;
> +
> + u8 init_buf[VMBUS_MAX_PACKET_SIZE];
> + u8 recv_buf[VMBUS_MAX_PACKET_SIZE];
> +
> + struct hv_device *hdev;
> +};
> +
> +#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev)
> +
> +/* -- */
> +/* Hyper-V Synthetic Video Protocol */
> +
> +#define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
> +#define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x)
> +#define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0x) >> 16)
> +#define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
> +#define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
> +#define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
> +
> +#define SYNTHVID_DEPTH_WIN7 16
> +#define SYNTHVID_DEPTH_WIN8 32
> +#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
> +#define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
> +#define SYNTHVID_WIDTH_MAX_WIN7 1600
> +
Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi,
> +/* Should be done only once during init and resume */
> +static int synthvid_update_vram_location(struct hv_device *hdev,
> + phys_addr_t vram_pp)
> +{
> + struct hyperv_device *hv = hv_get_drvdata(hdev);
> + struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> + unsigned long t;
> + int ret = 0;
> +
> + memset(msg, 0, sizeof(struct synthvid_msg));
> + msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> + msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> + sizeof(struct synthvid_vram_location);
> + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> + msg->vram.is_vram_gpa_specified = 1;
> + synthvid_send(hdev, msg);
That suggests it is possible to define multiple framebuffers in vram,
then pageflip by setting vram.vram_gpa. If that is the case I'm
wondering whenever vram helpers are a better fit maybe? You don't have
to blit each and every display update then.
FYI: cirrus goes the blit route because (a) the amount of vram is very
small so trying to store multiple framebuffers there is out of question,
and (b) cirrus converts formats on the fly to hide some hardware
oddities.
take care,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
DRM driver for hyperv synthetic video device, based on hyperv_fb
framebuffer driver. Also added config option "DRM_HYPERV" to enabled
this driver.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/tiny/Kconfig |9 +
drivers/gpu/drm/tiny/Makefile |1 +
drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
3 files changed, 1017 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa75..e6d53e60a9c2 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -28,6 +28,15 @@ config DRM_GM12U320
This is a KMS driver for projectors which use the GM12U320 chipset
for video transfer over USB2/3, such as the Acer C120 mini projector.
+config DRM_HYPERV
+ tristate "DRM Support for hyperv synthetic video device"
+ depends on DRM && PCI && MMU && HYPERV
+ select DRM_KMS_HELPER
+ select DRM_GEM_SHMEM_HELPER
+ help
+This is a KMS driver for for hyperv synthetic video device.
+If M is selected the module will be called hyperv_drm.
+
config TINYDRM_HX8357D
tristate "DRM support for HX8357D display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35f..837cb2c2637e 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_HYPERV) += hyperv_drm.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
diff --git a/drivers/gpu/drm/tiny/hyperv_drm.c
b/drivers/gpu/drm/tiny/hyperv_drm.c
new file mode 100644
index ..3d020586056e
--- /dev/null
+++ b/drivers/gpu/drm/tiny/hyperv_drm.c
@@ -0,0 +1,1007 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2012-2020 Microsoft
+ *
+ * Authors:
+ * Deepak Rawat
+ *
+ * Portions of this code is derived from hyperv_fb.c
+ * drivers/video/fbdev/hyperv_fb.c - framebuffer driver for hyperv synthetic
+ * video device.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "hyperv_drm"
+#define DRIVER_DESC "DRM driver for hyperv synthetic video device"
+#define DRIVER_DATE "2020"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+#define VMBUS_MAX_PACKET_SIZE 0x4000
+#define VMBUS_RING_BUFSIZE (256 * 1024)
+#define VMBUS_VSP_TIMEOUT (10 * HZ)
+
+#define PCI_VENDOR_ID_MICROSOFT 0x1414
+#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
+
+struct hyperv_device {
+ /* drm */
+ struct drm_device dev;
+ struct drm_simple_display_pipe pipe;
+ struct drm_connector connector;
+
+ /* mode */
+ u32 screen_width_max;
+ u32 screen_height_max;
+ u32 preferred_width;
+ u32 preferred_height;
+ u32 screen_depth;
+
+ /* hw */
+ void __iomem *vram;
+ unsigned long fb_base;
+ unsigned long fb_size;
+ struct completion wait;
+ u32 synthvid_version;
+ u32 mmio_megabytes;
+ bool init_done;
+
+ u8 init_buf[VMBUS_MAX_PACKET_SIZE];
+ u8 recv_buf[VMBUS_MAX_PACKET_SIZE];
+
+ struct hv_device *hdev;
+};
+
+#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev)
+
+/* -- */
+/* Hyper-V Synthetic Video Protocol */
+
+#define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
+#define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x)
+#define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0x) >> 16)
+#define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
+#define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
+#define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
+
+#define SYNTHVID_DEPTH_WIN7 16
+#define SYNTHVID_DEPTH_WIN8 32
+#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
+#define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
+#define SYNTHVID_WIDTH_MAX_WIN7 1600
+#define SYNTHVID_HEIGHT_MAX_WIN7 1200
+
+enum pipe_msg_type {
+ PIPE_MSG_INVALID,
+ PIPE_MSG_DATA,
+ PIPE_MSG_MAX
+};
+
+enum synthvid_msg_type {
+ SYNTHVID_ERROR = 0,
+ SYNTHVID_VERSION_REQUEST= 1,
+ SYNTHVID_VERSION_RESPONSE = 2,
+ SYNTHVID_VRAM_LOCATION = 3,
+ SYNTHVID_VRAM_LOCATION_ACK = 4,
+ SYNTHVID_SITUATION_UPDATE = 5,
+ SYNTHVID_SITUATION_UPDATE_ACK = 6,
+ SYNTHVID_POINTER_POSITION = 7,
+ SYNTHVID_POINTER_SHAPE = 8,
+ SYNTHVID_FEATURE_CHANGE = 9,
+ SYNTHVID_DIRT
