I just got a hex16b, there is a patch for cgminer but i cant figure out or find info on how to apply patch.
Any help appreciated. And thanks
Any help appreciated. And thanks
See the following quote:
If Kano and/or I have been offered new hardware, or offered support to develop drivers for hardware, we will develop and include the code in cgminer and actively maintain and develop it. With various manufacturers we have been engaged on this level at wildly different stages in development. Some very early in hardware development (like cointerra and hashfast), some just before distribution of the product (like BFLSC and bi*fury devices), some after the fact when manufacturer code and hardware has been out for a while (like kncminer and much later for avalon). These examples by no means include everyone. Our involvement in the driver has been proportional to the duration of our involvement.
If someone wishes to develop their own driver and are happy to maintain it for cgminer, they are welcome to submit a pull request for their code to the cgminer git tree - Note that it will not be instantly accepted but usually it's simply a matter of making their code consistent with cgminer and Kano and/or I will provide comments about what changes need to be made for the code to be included. While I can keep the code building satisfactorily with changes to cgminer, the onus will then fall upon the person who pushed the original code to maintain it and keep it up to date since neither Kano nor I can test changes to the driver without actually having the hardware ourselves. If down the track the original maintainer has not been keeping up to date with cgminer, and users report that the driver has stopped working, the original driver author will be contacted for fixes. If no fixes are forthcoming, the driver will then be removed from cgminer (this happened in the case of the ztex driver). With the very rapid pace of development of code in cgminer lately, this can happen all too easily. Historically this sort of code does not stand the test of time.
If there are drivers out there based on forked earlier cgminer code that we have never heard about, and the original author makes no attempt to get the code incorporated into cgminer, that code cannot be meaningfully incorporated into cgminer even if we're made aware of its existence for the same reason we cannot maintain code for hardware we don't have.
The device you're talking about belongs to the last categoryIf someone wishes to develop their own driver and are happy to maintain it for cgminer, they are welcome to submit a pull request for their code to the cgminer git tree - Note that it will not be instantly accepted but usually it's simply a matter of making their code consistent with cgminer and Kano and/or I will provide comments about what changes need to be made for the code to be included. While I can keep the code building satisfactorily with changes to cgminer, the onus will then fall upon the person who pushed the original code to maintain it and keep it up to date since neither Kano nor I can test changes to the driver without actually having the hardware ourselves. If down the track the original maintainer has not been keeping up to date with cgminer, and users report that the driver has stopped working, the original driver author will be contacted for fixes. If no fixes are forthcoming, the driver will then be removed from cgminer (this happened in the case of the ztex driver). With the very rapid pace of development of code in cgminer lately, this can happen all too easily. Historically this sort of code does not stand the test of time.
If there are drivers out there based on forked earlier cgminer code that we have never heard about, and the original author makes no attempt to get the code incorporated into cgminer, that code cannot be meaningfully incorporated into cgminer even if we're made aware of its existence for the same reason we cannot maintain code for hardware we don't have.
)
Manually re-plugged as AMU 34. Test continuing.