overdue-scratch

Author Topic: REQUIRED patches.  (Read 8438 times)

0 Members and 1 Guest are viewing this topic.

BuildSmart

  • Member
  • Posts: 30
REQUIRED patches.
« on: March 29, 2010, 01:35:28 PM »
I'm amazed that you still haven't fixed the build warnings after all this time.

People are coming to me and asking me to fix all kinds of stuff (because in most cases I am willing) and most of the fixes are related to the nvidia code which doesn't work properly and no one has really addressed it.

Still no QPI register detection/enabler code and you're still loading a DSDT file from disk instead of using BIOS calls to modify the embedded DSDT (you can remove and add devices from the embedded DSDT).

Here is my contribution to helping you improve your product, while it is not a complete fix, it does fix most of the nvidia related stuff and with the addition of roughly 14 lines of code you can fix all of the nvidia stuff with the exception of extracting the videoRam which as you should know requires the card to be initialized before it will calculate the amount of ram on it.

The changes should allow you to properly fix the ATI related code if you look at the nvidia.c file to see what is going on and use it as a model.

I realize this was applied against PCEFIV10.6 but since the code-base is basically the same, integration shouldn't be that difficult.

I spent about 15 minutes on it, built it and then generated a diff.

I have a binary with additional fixes in the nvidia related code if you want to visit my IRC and discuss/try it you are welcome to do so.

The diff of the required changes is attached.


Lord Anubis

  • Member
  • Posts: 74
Re: REQUIRED patches.
« Reply #1 on: March 29, 2010, 11:25:57 PM »
instead of using BIOS calls to modify the embedded DSDT (you can remove and add devices from the embedded DSDT).

just a question.
Is this World Width Universal to all mobo's and their Bioses?
Does every Bios have the same dsdt add calls?
Quicksilver 2002 Case - GB EP45-DS3P - 8Gb Kingston mem. - Q6600 - Asus 7300GT Silent 512Mb - 6 SATA drives - 1 IDE drives ( using F12/Chameleon for booting, not visible in OSX ) - 1 external Sata Samsung DVD - OSX 10.6.8 server retail - Chameleon 2.0RC1 + Cartri Bios

zef

  • Administrator
  • Posts: 265
Re: REQUIRED patches.
« Reply #2 on: March 29, 2010, 11:30:01 PM »
The diff of the required changes is attached.

Hi BuildSmart,

thx for the patches. In the middle of January Chameleon is moved to a public repository. Can you please inspect the changes there and re-apply yours against the latest trunk rev please?

http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk

Thx,
zef
ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

BuildSmart

  • Member
  • Posts: 30
Re: REQUIRED patches.
« Reply #3 on: March 31, 2010, 05:54:10 AM »
instead of using BIOS calls to modify the embedded DSDT (you can remove and add devices from the embedded DSDT).

just a question.
Is this World Width Universal to all mobo's and their Bioses?
Does every Bios have the same dsdt add calls?
As far as I have been able to confirm yes, this seems to be the norm for EFI bases BIOSes.

BuildSmart

  • Member
  • Posts: 30
Re: REQUIRED patches.
« Reply #4 on: March 31, 2010, 08:33:31 AM »
The diff of the required changes is attached.

Hi BuildSmart,

thx for the patches. In the middle of January Chameleon is moved to a public repository. Can you please inspect the changes there and re-apply yours against the latest trunk rev please?

http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk

Thx,
zef
Asking me to apply patches to a different code base and expecting it to work is dangerous however it is your code and I had 5 minutes, I applied the changes to your code base and have attached a diff.

Please bear in mind, I am unable to test these changes to your boot loader code since I don't have any HD with your setup installed and cant waste the time playing with it for your benefit, the patches applied to PCEFIV10.6 were tested and were working with one minor error in pci.c (the sub_id should retrieve from PCI_SUBSYSTEM_VENDOR_ID and not PCI_VENDOR_ID - fixed in yours).

The system that these fixes were generated for has been returned but I thought that you should at least benefit from better nVidia code and maybe someone else who uses your code might take it upon themselves to finish it since it's really close to being done as provided.

It still needs work and I didn't fix everything (it's not my code base) but what I did rewrite corrects a lot.

So my advice, you would be wise to take the diff, apply it and test it to ensure it's working properly before committing it (in case you need to make adjustments) and, to get it to actually extract the ROM image from the additional cards requires about another 12 lines of code since your original code never disabled the primary card, enabled the additional card, retrieved the ROM then disabled the additional and reactivated the primary card so it just copied the current active ROM shadowed at 0xC0000 which is not the ROM you want if the cards are different.

Also note, the legacy ability to load a ROM file based on the cards ID so you can load a different ROM, for example, an 8800GTS which has a problematic ROM by loading the 9800GT ROM in it's place (or any other ROM that works for it).

One more note, the ATI code needs serious work, if it does anything it does it incorrectly, the ATI programming documentation suggests heavy use of CONFIG and STATUS registers to help obtain data which as you can see clearly doesn't occur and they outline a struct to retrieve data where you retrieve one byte at a time using consecutively coded read statements which waste space and time.

fassl

  • VoodooLabs
  • Posts: 29
Re: REQUIRED patches.
« Reply #5 on: April 03, 2010, 03:49:07 AM »
Hi guys, i took a quick look at the diff, i dont see it injecting "vbios" property anymore anywhere. We patch the DCB table of the target nvidia cards and thus have to inject the modified bios into ioreg for the changes to take effect.

greets

zef

  • Administrator
  • Posts: 265
Re: REQUIRED patches.
« Reply #6 on: April 03, 2010, 11:06:00 AM »
Hi guys, i took a quick look at the diff, i dont see it injecting "vbios" property anymore anywhere.

Hi Fassl,

How about nvidia.c line 800?

http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/nvidia.c#L800

ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

fassl

  • VoodooLabs
  • Posts: 29
Re: REQUIRED patches.
« Reply #7 on: April 03, 2010, 03:01:26 PM »
Hi zef, true didnt look at this code just at the diff. Anyway "vbios" should be injected by default (wasn't it that way in early stages?), since we patch the DCB table of almost every card to suit. Like BuildSmart said already nvidia code is quite a mess, but there is work going on for next NVEnabler already, and i'll update nvidia GraphicsEnabler as well when its ready. Thx to BuildSmart for cleaning up so far ;)

greets

BuildSmart

  • Member
  • Posts: 30
Re: REQUIRED patches.
« Reply #8 on: April 04, 2010, 09:12:42 AM »
zef, your current code does not obtain a rom for each card because the code isn't doing what it should be doing.

You need to consider the following facts
  • either you use NVEnabler (which has it's own issues) or you use a solution in your code base.
  • your code makes a single pass of the PCI bus without enabling all devices and associated configuration space.
  • the current register code is limited in functionality and access.
  • the current code does not work properly with multiple cards.
  • the nvidia code I provided has improved register functions (a quick look should show you this).
  • injecting vbios in most cases seriously damages performance and is not the recommended solution.
  • you do not build and inject NVMT data based on the DCB or PCT.
  • you do not capture or mark the active display port.
  • you do not provide an NVCAP that is NV_40 or NV_50 compliant.
  • you do not extract and inject EDID information for the active primary display port.
  • your current method does not properly configure additional nVidia cards.

I've rewritten a lot of the code to be less memory intensive and more efficient but since your project is not anything I personally use it's hard to offer a complete integrated solution because there is so much wrong in other places.

The fact that you patch the DCB loses any integrity you intend to achieve the moment you swap ports because these are keyed to hardware registers and the registers themselves are not compensated.

Swapping the ports in the NVCAP is an acceptable solution if you need to swap the ports and is the only acceptable solution according to nVidia.

The use of hard-coded NVMT data is just out-right stupid since you have the ability to read all the registers you can determine what display port is active and what information is available for the available ports on the card and provide this data on a per-card basis instead of using hard-coded data which is for a different card.

Yes, if you create NVMT data then not only can you have 2 ports but the OS better utilizes the available ports by the data provided for the ports and you don't need to inject a virtual bios.

Original thinking was that this NVMT information is constant so they hard coded NVMT values but they failed to acknowledge or recognize that this information is based on the cards ports and it's capabilities and that it is different for every card.

Before you can poll additional nVidia devices you must disable the primary nVidia device, enable the additional nVidia device, initialize the additional nVidia device, poll it's registers for the required data, disable the additional nVidia device and re-enable the primary nVidia device.

You'll know you have this code working properly when you can extract the cards VRAM (best tested with 2 cards of differing amounts memory).

Most of the code I have doesn't integrate well with the current line of boot loaders and I'm not entirely sure I'm interested in releasing any of the code I currently use however, I was asked to help a friend with a solution and I just thought you would benefit from the better code.

What I have provided is substitute code which offers improved results and performance.

What I have not provided is code to manage the additional cards because I don't have the time to exclusively work on a project I don't use.

All I can do is offer advice on what you need to do and I would first start by implementing the code I have provided, next I would assign this portion of the project to someone competent and interested in completing it.

At that time I could then find some time to help them finish the code by tackling the remaining obstacles one at a time in a method conducive to your code base but doing it here in the forum would take several months to code and an unknown amount of time to debug any issues which would mean roughly a year before you saw anything that I would consider stable and usable so an IRC would be the place to discuss and work on the project.

While this is being done, a rewrite of the PCI bus scanning code to include rescanning capabilities could be done by someone else and this I would consider a priority since you want to fix the CPU/FSB detection code.

fassl

  • VoodooLabs
  • Posts: 29
Re: REQUIRED patches.
« Reply #9 on: April 04, 2010, 02:22:24 PM »
BuildSmart, you keep telling facts without any proof.

"injecting vbios in most cases seriously damages performance and is not the recommended solution."

We have to inject vbios, since we alter DCB table, and if you look at the code carefully you will see that we dont swap outputs, we alter the HEADS bit of the DCB entries to be either "1" or "2". Which is needed to get dual screen working correctly. Yet i want to see this performance loss, maybe you can provide some benchmark.

"you do not build and inject NVMT data based on the DCB or PCT"

Again, proof? NVMT is not about DCB, look at any mac nvidia efi module.

"you do not provide an NVCAP that is NV_40 or NV_50 compliant."

Shouldn't matter since they are built up the same way, but will be looked at.


greets fassl

BuildSmart

  • Member
  • Posts: 30
Re: REQUIRED patches.
« Reply #10 on: April 05, 2010, 01:55:50 AM »
I don't have the time to waste on benchmarking anything not related to code I implement and some of the things I have stated are obvious.

If you don't believe performance is affected by injection of a virtual bios insert 2 different cards alter and inject a virtual bios for each card and then create (valid) NVMT data for each card and inject it and tell me it isn't more responsive.

Bloating the device-properties with 64k of rom for each video card doesn't make a lot of sense when this can be reduce to less than 128 bytes per card by producing NVMT data and yes, processing large device-properties data takes time and the time is noticeable, especially when it contains three 64k rom blobs.

The DCB does not need to be altered, you do it because you do not encode/inject NVMT, this of course requires injection of the altered virtual bios to keep your intended configuration which bloats the device-properties and thus takes more time to process and you think this doesn't have any negative impact on performance or functionality?

Here is something factual again, not all cards work with/from a virtual bios and some cards will not work with other cards when a virtual bios is introduced and bofors can confirm this, we spent three days working this conflict before figuring out what the problem was.

The apple EFI generated and injected NVMT data provides information to decode the DCB and PCT, is significantly smaller in size and takes less time to generate than extracting a rom image, patching the DCB and injecting the (patched/altered) rom and then processing it, why do you think apple does it the NVMT way?

The information contained in the NVCAP can affect a cards performance as well as providing quick access to port assignments for drivers, I have found 5 different versions of apple NVCAP data based on the a cards chipset (I don't have every apple nVidia card so there could be more), 3 are pretty much the minimum I would suggest be implemented, a simple switch/case can provide the correct version of the NVCAP data for alteration.

The other issue with the current trend of NVCAP data/injection is that it is not understood, the first byte actually tells the driver something, the 0x07 near the end people assume is a static value with no bit assuagement is also an incorrect assumption along with all of the 0x00 values in between, think of the NVCAP as a set of consecutive 8bit and 16bit registers, some registers are reserved and should remain 0x00 while others can be altered to change behavior.

Since the goal is to obtain the greatest compatibility amongst non-native cards a little tradeoff is expected and you should be able to get away with 3 different versions of NVCAP data without seriously sacrificing performance.

Tell me that the following two NVCAP's create the same performance in the test card:
Code: [Select]
/* test card - BFG GT120 512mb */

#define OLD_NVCAP 0

#if OLD_NVCAP == 0
uint8_t NVCAP[] =
{
    0x04, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x03, 0x00,
    0x1c, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x07,
    0x00, 0x00, 0x00, 0x00
};
#else
uint8_t NVCAP[] =
{
    0x05, 0x01, 0x00, 0x00,
    0x00, 0x00, 0x03, 0x00,
    0x1c, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x0a, 0x0b,
    0x00, 0x00, 0x00, 0x00
};
#endif
If you think they do then you need to test this cause I see 1 byte that puts the card in a faster clock rate and that means faster GPU processing.

As I said, I have time to help someone with the code but I don't have time to do it myself, if you wish to take advantage of my assistance great, if not that's OK too, I just don't have the time to work on a project I don't use and have no way of testing so assign it to someone and have them see me if you want my assistance.

fassl

  • VoodooLabs
  • Posts: 29
Re: REQUIRED patches.
« Reply #11 on: April 05, 2010, 03:02:25 PM »
Quote
The DCB does not need to be altered, you do it because you do not encode/inject NVMT, this of course requires injection of the altered virtual bios to keep your intended configuration which bloats the device-properties and thus takes more time to process and you think this doesn't have any negative impact on performance or functionality?

In fact it had to be. You can only see Head 1 or 2 in mac roms for each dcb entry, whereas PC roms have 3 as well. For instance we had a S-Video out and its dcb entry had head 3, either it was not working or randomly, when we patched it with 2 it suddenly was ok.

Quote
The apple EFI generated and injected NVMT data provides information to decode the DCB and PCT, is significantly smaller in size and takes less time to generate than extracting a rom image, patching the DCB and injecting the (patched/altered) rom and then processing it, why do you think apple does it the NVMT way?

Again, i cant see anything DCB related to NVMT, display-cfg and NVCAP are for that. NVMT provides information about the primary display. What you mean with PCT i have no clue.

Quote
If you don't believe performance is affected by injection of a virtual bios insert 2 different cards alter and inject a virtual bios for each card and then create (valid) NVMT data for each card and inject it and tell me it isn't more responsive.

I don't know every bit of NVMT yet, if you do you are welcome to post its structure here.

Quote
The other issue with the current trend of NVCAP data/injection is that it is not understood, the first byte actually tells the driver something, the 0x07 near the end people assume is a static value with no bit assuagement is also an incorrect assumption along with all of the 0x00 values in between, think of the NVCAP as a set of consecutive 8bit and 16bit registers, some registers are reserved and should remain 0x00 while others can be altered to change behavior.

The first byte, i call it NVCAP version, since i've seen a mac card with nvidia arch 40 and a NVCAP starting with 5.
Well the 0x07 you are talking about is hardcoded in the efi modules, so hard to find what they mean there, one would need to look into NVDAResman what it is for. And about the other values, yes we don't set them yet, but we know what most of them are for.

BuildSmart, i don't want to offend you or something, this thread will most likely go on forever, yet i'm curious if you will provide real information some time. With real information i mean stuff like: "Hey NVMT WORD 3 is EDID_MANUFACTURER"? Rather than taking assumptions and posting it here without any prove again. If you are so sure about NVMT and NVCAP i ask you to post your information here, and i'll tell you if i came up with the same thing.

BuildSmart

  • Member
  • Posts: 30
Re: REQUIRED patches.
« Reply #12 on: April 05, 2010, 05:27:02 PM »
Detailed technical information in a post discussing working on a solution has no real value and I fail to see the benefit of discussing it here unless this is how/where you want to work on it however I'll give you some since you seem to be requesting something from me rather than obtaining the technical documentation from nVidia.
    STATUS REGISTER byte 0/1: 16bit register
    • bit 15-13 unknown
    • bit 12-11 backlight state
    • bit 10 backlight timer
    • bit 9 device attached port 1
    • bit 8 device attached port 0
    • bit 7-5 reserved
    • bit 4 primary port 1
    • bit 3 primary port 0
    • bit 2 port 2 (optional port if available)
    • bit 1 port 1 available
    • bit 0 port 0 available
    CONTROL REGISTER bytes 3+1: (+1) 8bit register
    • bit 7 SECAM/PAL-AUTO (on cards that support it)
    • bit 6 PAL 60 (on cards that support it)
    • bit 5 PAL 50 (on cards that support it)
    • bit 4 PAL N (on cards that support it)
    • bit 3 NTSC mixed mode (on cards that support it)
    • bit 2 NTSC (on cards that support it)
    • bit 1 NTSC dual RAMDAC (on cards that support it)
    • bit 0 NTSC hi-speed clock (on cards that support it)

    PCT (peripheral configuraiton table) is a table which contains information about devices such as built-in LCD, lid switches, auto backlight, auto brightness etc... which cannot be disconnected or removed but can be disabled or turned off.

    For NVCAP's my apple 7300GT gives me 0x0004/0x0700, my apple 7600GT card is supplying a 0x0004/0x0A00, the apple 9600GT gives me 0x0105/0x0901 and my apple GT120 is supplying 0x0005/0x0B00 and they all work with 0x0004/0x0700 but they certainly don't perform optimally with incorrect value.

    NVMT doesn't seem to be changing when I connect an apple 17" CRT which can only do 640x480 @60hz, 800x600 @60hz and 1024x768 @95hz and the apple 30" LCD which is defaulting to 1920x1200 @60hz in it's initial state and 2560x1600 @60hz at desktop, all I see change is the EDID of the connected device so apple must be hard-coding the NVMT data since it doesn't change????






    It's a known fact that I am not a people person, and don't particularly like environments where I am grilled for details and information from someone who I don't believe is a participator in the open-source community.

    I'm not interested in sitting here and discussing in great length and detail the information for solving any of the problems I might be in possession of and while fassl expressed an interest to know something, I've waited for someone responsible for this code to accept my offer of assistance and begin working on the issues which has not occurred and my interest in helping has now faded.

    I offered an invitation to work with the person responsible for this portion of the project and this was not accepted, instead I get fassl asking a million question trying to involve me in a public discussion and provide information that he can use and I'm not interested in discussing details and solving problems on a forum because the medium takes far to long to produce any results, had someone stepped up to the plate I'm sure I could have provided enough code that someone could have transcribed and integrated it into the existing code-base and had something testable by now

    zef/fassl, if you want to run with the code I provided knock yourself out, I hope you solve the issues with the nvidia code and make it be all that it can be, there is nothing more that can be discussed in a thread on solving the problems and no one has expressed a desire in working with me to solve the remaining issues so I'll leave you to solving the issues on your own.
« Last Edit: April 06, 2010, 09:04:52 AM by BuildSmart »

fassl

  • VoodooLabs
  • Posts: 29
Re: REQUIRED patches.
« Reply #13 on: April 06, 2010, 04:35:48 PM »
Quote
It's a known fact that I am not a people person, and don't particularly like environments where I am grilled for details and information from someone who I don't believe is a participator in the open-source community.

The only thing i made not open source was NVEnabler, but we (Krazubu works with me on nVidia injection) built GraphicsEnabler up on NVEnabler anyway. Its patching and NVCAP generation is the same, well quite the same, there is a bit of a difference in NVCAP generation to the NVEnabler.kexts floating around, but thats because i lost the source of the NVEnabler floating around and had to take an older code base.

Quote
I'm not interested in sitting here and discussing in great length and detail the information for solving any of the problems I might be in possession of and while fassl expressed an interest to know something, I've waited for someone responsible for this code to accept my offer of assistance and begin working on the issues which has not occurred and my interest in helping has now faded.

What are you interested in then? And what is this part of the forum about when its not about discussing information in detail and length? I said already, if you know something then post it here. If not, well then not. You seemed to know what NVCAP, NVMT is about, well then show me that you know it. All you said so far shows me you don't. If you want and can prove me otherwise and we can share our findings here.

Quote
I offered an invitation to work with the person responsible for this portion of the project and this was not accepted, instead I get fassl asking a million question trying to involve me in a public discussion and provide information that he can use and I'm not interested in discussing details and solving problems on a forum because the medium takes far to long to produce any results, had someone stepped up to the plate I'm sure I could have provided enough code that someone could have transcribed and integrated it into the existing code-base and had something testable by now

I am responsible for that portion of the project. If you mean i should join your irc, no thanks. Things don't work that way. If you have something useful, some patch to provide, you are welcome to post it here. And it is not about information that i can use, it is about information that will help all people with nvidia cards. If you were really able to tell i guess you would have done already? And if you already have enough code, why dont you post it (that would actually help you know ;) ), or even better, why dont you release your own product?

Quote
zef/fassl, if you want to run with the code I provided knock yourself out, I hope you solve the issues with the nvidia code and make it be all that it can be, there is nothing more that can be discussed in a thread on solving the problems and no one has expressed a desire in working with me to solve the remaining issues so I'll leave you to solving the issues on your own.

I havent tested your changes, yet i thanked you for your contribution. Also i am more interested in generating and injecting correct values for a card, rather than getting two cards working at once. That should be the last bit we should care about in my opinion. When we can inject one card properly, we can inject a second as well.

And yet again you lost interest suddenly. Guess it goes that way always with you. Actually i hate such discussions and i could shoot in my back for starting it. But it has to be said, you keep telling us all what we all do wrong and that you know it better and you have ready patches etc. But when it comes to a showdown you suddenly lose interest, because we don't want to join your irc to discuss with you or whyever i don't know. I don't know, maybe its just me, but i saw this behaviour of you on other threads as well. If you have information to share, share it, but please dont start public discussions showing you off as guru and putting creators of a project in the corner showing the finger at him "You do it wrong". For an uninvolved visitor it looks like the creators of a project do it wrong with you as mentor showing us how to do it, and then suddenly lose interest because it looks like we all dont know what we are doing but you are and we are not worth to share your knowledge. And i can't stand such behaving, hence i started this catfight, which for me is over with this post.

greets fassl
« Last Edit: September 15, 2011, 10:10:11 PM by fassl »

BuildSmart

  • Member
  • Posts: 30
Re: REQUIRED patches.
« Reply #14 on: April 07, 2010, 01:08:57 PM »
fassl, I could care less where the work actually occurs but have no interest in doing your work or posting millions of lines of proprietary code in a forum thread to help you understand anything and it is wrong of you to think that I need to do any of this to help you solve anything.

I could also care less what you release and don't release, your work is yours and has nothing to do with me and yes, there are some versions of NVEnabler source floating around so I certainly wouldn't call it closed source.

I will state again just for you so you understand exactly what I have stated previously, I have no patch that can be applied to this code base because I do not use it and cannot test it.

I did the preliminary patch as a courtesy to zef and was the extent of the work I was willing to perform since I could not test it but you pretty much killed any future offerings because you try to force people into involvment rather than accept any involvement they might be offering.

Expecting me to generate a patch was never going to happen and was very clear by the remarks I made, I would have provided whomever with the nVidia programming documentation and some code to fill in the missing functionality and they would have had to modify it to work with the code base and that would have been the extent of my participation.

You expect me to produce a patch or finished, tested and working solution you expect too much from someone not associated with or using this project.

You were not required to join my IRC or forum, what was expected was communication in real time outside of this forum but you kept pushing for it to occur in this thread and that is why I lost interest, I'm not interested in dealing with your demanding ways.

I'm not here to endorse your work, convince you of anything or teach you anything, I would have discussed whatever changes were made to the code and then offered the the missing pieces which would have needed some finessing because the current code-base does not use BIOS or EFI calls to perform any tasks so integration would have required some modification.

You demanded information, I gave some to you and you ignored it, now you're telling me you are the responsible party for this portion of code and demand I produce and provide information and code here, you should have told me you were responsible sooner then I would have requested a venue for real-time conversation to further discuss the solutions rather than have you waste time trying to force it to happen here.

If you really wanted to discuss in detail what information I had then you should have made an effort to have a real-time conversation outside this forum as I had requested rather than continue trying to force it to happen here for a project I don't use and have nothing to do with and by your own remarks you expected patches and code to be provided here despite me voicing it wouldn't happen here is a sign that you weren't expecting help with finishing it but rather demanded I handed it to you which meant I would have had to do your work for you.

If I was able to test the project with little effort I might have finished it but since I couldn't test what was already provided I figured I'd wait for the responsible party and help them finish it since they would have been able to test it.

Admitting that the nvidia code is based on your NVEnabler work now gives everyone the impression that it's likely a nightmare in need of work.

And just so you are clear in understanding why, I didn't suddenly lose interest, it was your demanding I work on it here that made me lose interest as I expressed it wouldn't happen here and now I can understand and sympathize  why people refrain from participating in zef's project due to your involvement despite the appearance of any benefit your presence brings.

Zef, I wish you and your project well and hope it goes in the direction you are anticipating.